내 / 파티션의 모든 공간을 어떻게 사용하고 있는지 어떻게 알 수 있습니까?

Amazon EC2 서버에서 대규모 인스턴스를 사용하고 있습니다. df 명령을 실행하고 다음을 얻습니다.

root@db:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.9G  9.1G  284M  98% /
tmpfs                 3.8G     0  3.8G   0% /lib/init/rw
varrun                3.8G  116K  3.8G   1% /var/run
varlock               3.8G     0  3.8G   0% /var/lock
udev                  3.8G   80K  3.8G   1% /dev
tmpfs                 3.8G     0  3.8G   0% /dev/shm
/dev/sdb              414G  957M  392G   1% /mnt
/dev/sdf               50G   12G   35G  26% /byp
/dev/sdk               99G   31G   63G  33% /backups

그런 다음 du 명령을 실행하고 다음을 얻습니다.

root@db:/# du -s -h /*
31G     /backups
5.5M    /bin
136K    /boot
12G     /byp
80K     /dev
5.8M    /etc
12K     /home
70M     /lib
11M     /lib32
0       /lib64
16K     /lost+found
759M    /mnt
4.0K    /opt
du: cannot access `/proc/6917/task/6917/fd/4': No such file or directory
du: cannot access `/proc/6917/fd/4': No such file or directory
0       /proc
31M     /root
7.7M    /sbin
4.0K    /selinux
4.0K    /srv
0       /sys
11M     /tmp
1.1G    /usr
114M    /var

알 수없는 경우, 마운트되지 않은 디렉토리의 du 명령 출력에서 ​​모든 크기를 합산하면 df 명령에서 볼 수 있듯이 9.1G에 가까운 곳은 없습니다.

디스크가 불량하다는 의미입니까? 그렇다면 어떻게 해결할 수 있습니까?

프로세스에 여전히 열린 파일 핸들이있는 매우 큰 삭제 된 파일 (또는 많은 작은 파일)이있을 수 있습니다. 그들을 찾는 방법은 실행하는 것입니다

# lsof | grep "deleted"

"(삭제됨)"으로 끝나는 줄이 많이 있으면 프로세스 ID를 찾아서 다시 시작할 수 있습니다. 그런 일이 발생하면 디스크 공간이 반환됩니다.

이 방법으로 문제가 해결되지 않으면 fsck를 권장합니다.

du가 df와 같지 않은 데에는 여러 가지 이유가 있습니다. 이 질문에 대한 답변을 참조하십시오 .

일부는 오버레이 마운트, 많은 작은 파일 및 더 큰 블록 크기 및 여전히 사용중인 삭제 된 파일입니다. 오버레이 마운트는 파일 시스템을 파일이 마운트 된 마운트 포인트에 마운트했을 때 표시되지 않습니다.

이 둘의 주된 차이점은 df는 수퍼 블록을 확인하고 신뢰한다는 것입니다. du는 볼 수있는 모든 파일을 스캔하여 추가합니다. 수퍼 블록에 대한 정보는 이 IBM 링크 를 참조하십시오 .

이와 같은 문제점을 추적 할 때는 항상 du와 함께 -x 옵션을 사용하십시오. 파일 시스템을 가로 지르는 것을 방지합니다.