디스크가 꽉 찼습니다. 더 조사하는 방법?

서버 (하드웨어 RAID 1), 32G, ext3 파일 시스템에 SCSI 디스크가 있습니다. df디스크가 100 % 가득 찼음을 알려줍니다. 1G를 삭제하면 올바르게 표시됩니다.

그러나 a du -h -x /를 실행하면 du12G 만 사용된다고 알려줍니다 ( -x일부 Samba 마운트 때문에 사용합니다 ).

그래서 내 질문은 du와 df 명령의 미묘한 차이점이 아니라이 큰 차이점의 원인을 어떻게 알 수 있는지에 관한 것입니다.

오류가 발생한 fsck를 위해 시스템을 재부팅했습니다. 내가 실행해야합니까 badblocks? lsof열린 삭제 된 파일 lost+found이 없으며 비어 있으며 메시지 파일에 명백한 경고 / 오류 / 실패 문이 없습니다.

설정에 대한 자세한 내용은 언제든지 문의하십시오.

마운트 지점 아래에있는 파일을 확인하십시오. 디렉토리 (예 : sambafs)를 이미 파일이나 그 아래에있는 파일 시스템에 마운트하면 해당 파일을 볼 수 없게되지만 여전히 기본 디스크의 공간을 사용하고 있습니다. 단일 사용자 모드에서 단일 사용자 모드를 제외하고 볼 수없는 디렉토리에 파일을 덤프했습니다 (다른 디렉토리 시스템이 마운트되어 있기 때문에).

로컬 서버에서 문제를 추적하려고 할 때이 페이지가 우연히 발견되었습니다.

내 경우에서 df -h와 du -sh하드 디스크 크기의 약 50 % 일치하지.

디스크에서 삭제 된 메모리에 큰 로그 파일을 유지하는 아파치 (httpd)로 인해 발생했습니다.

이것은 정리해야 할 파티션이있는 lsof | grep "/var" | grep deleted곳 을 실행 하여 추적 /var했습니다.

출력 결과는 다음과 같습니다.
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

그런 다음 아파치 ( service httpd restart) 를 다시 시작하여 상황을 해결하고 삭제 된 파일의 잠금을 해제하여 2GB의 디스크 공간을 정리했습니다.

귀하의 "누락 된"공간에 대한 가장 가능한 원인으로 OldTroll의 답변에 동의합니다.

Linux에서는 전체 루트 파티션 (또는 그 문제에 대한 다른 파티션)을 파일 시스템의 다른 위치에 / mnt와 같이 쉽게 다시 마운트 할 수 있습니다.

mount -o bind / /mnt

그럼 당신은 할 수 있습니다

du -h /mnt

당신의 공간을 어떻게 사용하는지보십시오.

추신 : 코멘트가 아닌 새로운 답변을 추가하여 죄송하지만이 게시물을 읽을 수 있도록 몇 가지 형식이 필요했습니다.

무슨 df -i말을 참조하십시오 . 사용 가능한 공간을 모두 소비하지 않고 사용 가능한 모든 inode를 사용하는 파일 시스템에 많은 수의 작은 파일이있는 경우 발생할 수있는 inode가 없을 수 있습니다.

필자의 경우 이것은 큰 삭제 된 파일과 관련이 있습니다. 이 페이지를 발견하기 전에 해결하기가 상당히 어려웠으므로 올바른 경로로 설정되었습니다.

마지막으로을 사용하여 문제를 해결했습니다 lsof | grep deleted.이 프로그램은 두 개의 매우 큰 로그 파일 (사용 가능한 8GB 루트 파티션의 총 5GB)을 보유하고있는 프로그램을 보여줍니다.

프로그램에 의해 열린 파일은 파일을 삭제할 때 실제로 사라지지 않으며 (디스크 공간 소비 중지) 프로그램을 닫을 때 사라집니다. 프로그램에는 사용자 (및 du)가 볼 수없는 거대한 임시 파일이있을 수 있습니다. 좀비 프로그램 인 경우 해당 파일을 지우려면 재부팅해야합니다.

디스크에 쓰는 동안 죽은 / 중단 된 프로세스가 잠겨 있는지 확인하려면 다음을 시도하십시오. lsof | grep "/ mnt"

그런 다음 붙어있는 PID를 제거하십시오 (특히 "(삭제됨)"으로 끝나는 줄을 찾으십시오)

이것은 큰 파일을 찾기 위해 지금까지 찾은 가장 쉬운 방법입니다!

루트 마운트가 꽉 찬 경우의 예는 다음과 같습니다 (예 : / root). 예 :

cd / (그래서 당신은 루트에 있습니다)

LS | xargs du -hs

출력 예 :

 9.4M 빈
 63M 부팅
 4.0K cgroup
 680K 개발
 31M 등
 6.3G 홈
 313M 라이브러리
 32M lib64
 16K 손실 + 발견
 61G 미디어
 4.0K mnt
 113M 선택
 du :`proc / 6102 / task / 6102 / fd / 4 '에 접근 할 수 없습니다 : 그러한 파일이나 디렉토리가 없습니다
 프로세스 0
 19M 루트
 840K 달리기
 19M 스빈
 4.0K selinux
 4.0K srv
 25G 스토어
 26M tmp

그런 다음 상점 이 크다는 것을 알 수 있습니다 . cd / store

다시 실행

LS | xargs du -hs

출력 예 : 
 109M 백업
 358M fnb
 4.0G 이소
 8.0K 킬로그램
 16K 손실 + 발견
 47M 루트
 11M 스크립트
 79M tmp
 21G VMS

이 경우 vms 디렉토리는 스페이스 호그입니다.

나를 위해, sudo가 아닌 사용자가 읽을 권한이없는 sudo du많은 양의 docker 파일이 있었기 때문에 실행해야했습니다 /var/lib/docker.

고려해야 할 또 하나의 가능성-도커를 사용하는 경우 큰 불일치가 거의 보장되며 볼륨 마운트를 사용하는 컨테이너 내에서 df / du를 실행합니다. 도커 호스트의 볼륨에 마운트 된 디렉토리의 경우 df는 HOST의 df 합계를보고합니다. 당신이 그것에 대해 생각한다면 이것은 분명하지만, "디스크를 채우는 런 어웨이 컨테이너!"에 대한 보고서를받을 때, 컨테이너의 파일 공간 소비를 다음과 같은 것으로 확인하십시오 du -hs <dir>.

그래서 Centos 7 에서도이 문제가 있었고 각각 약 7G를 보였지만 bleachbit 및 / usr 및 / var 청소와 같은 많은 것들을 시도한 후에 해결책을 찾았습니다. 루트 파티션에 사용 된 50G의 50G는 여전히 표시되지만 파일 사용은 9G 만 표시했습니다. 라이브 우분투 CD를 실행하고 문제가있는 50G 파티션을 마운트 해제하고 터미널을 열고 파티션에서 xfs_check 및 xfs_repair를 실행했습니다. 그런 다음 파티션을 다시 마운트하고 lost + found 디렉토리가 40G로 확장되었습니다. lost + found를 크기별로 정렬하고 스팀에 대한 38G 텍스트 로그 파일을 찾았습니다. 큰 파일을 제거했으며 이제 공간이 있고 디스크 사용량이 루트 파티션 크기와 일치합니다. 증기 로그가 다시 커지지 않도록하는 방법을 여전히 알고 싶습니다.

마운트 된 디스크가 Windows 시스템의 공유 폴더 인 경우, df는 전체 Windows 디스크의 크기와 디스크 사용을 표시하지만 du는 액세스 한 디스크의 일부만 표시합니다. (그리고 장착). 따라서이 경우 Windows 시스템에서 문제점을 수정해야합니다.

프로덕션에서도 비슷한 일이 발생했으며 디스크 사용량은 98 %로 증가했습니다. 다음 조사를 수행했습니다.

a) df -iinode 사용량을 확인하기 위해 inode 사용량이 6 %이므로 파일 크기가 훨씬 작습니다.

b) root숨겨진 파일 마운트 및 확인 추가 파일을 제출할 수 없습니다 . du결과는 마운트 전과 동일합니다.

c) 마지막으로, 확인 된 nginx로그. 디스크에 쓰도록 구성되었지만 개발자는 로그 파일을 직접 삭제하여 nginx모든 로그를 메모리에 보관합니다. 파일 /var/log/nginx/access.log을 사용하여 디스크에서 파일 을 삭제 했으므로 파일을 rm사용하여 볼 수 du없었지만 파일이 액세스되어 파일 nginx이 계속 열려 있습니다.

이 주제에서 언급 된 것과 동일한 문제가 있지만 하나의 VPS에서 발생했습니다. 그래서 나는이 주제에서 설명 된 모든 것을 테스트했지만 성공하지 못했습니다. 이 솔루션은 할당량 재 계산을 수행의 공간 차이를 보정 우리의 VPS 제공자와 지원을위한 접촉했다 df -h및 du-sh /.

나는 오늘 FreeBSD 상자 에서이 문제에 부딪쳤다. 문제는 그것이 인공물이라는 것입니다 vi( 이 문제를 일으킬 vim지 확실하지 않습니다 vim). 파일이 공간을 소비했지만 디스크에 완전히 기록되지 않았습니다.

다음을 통해 확인할 수 있습니다.

$ fstat -f /path/to/mount/point |sort -nk8 |tail

그러면 열려있는 모든 파일 -n을보고 8 번째 열 (키, -k8) 별로 (숫자를 통해 ) 정렬 하여 마지막 10 개 항목을 표시합니다.

필자의 경우 최종 (최대) 항목은 다음과 같습니다.

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

이는 프로세스 (PID) 12345가 디스크를 du인식 하지 못하더라도 1.46G (8 번째 열을 1024³로 나눈 값)의 디스크를 소비 함을 의미 했습니다. vi매우 큰 파일을 보는 것이 끔찍합니다. 심지어 100MB도 큽니다. 1.5G (또는 실제로는 파일이 큰 것)는 말도 안됩니다.

해결책은 sudo kill -HUP 12345(그것이 효과가 없다면, 나는 그것을 sudo kill 12345실패했을 경우, 두려운 kill -9사람들이 작용할 것입니다)입니다.

큰 파일에 텍스트 편집기를 사용하지 마십시오. 빠른 스키밍을위한 샘플 해결 방법 :

합리적인 라인 길이 가정 :

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

불합리하게 큰 라인을 가정하면 :

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

설치 vim -R되는 대신 거의 항상 더 좋기 view때문에 대신 사용 하는 vim것이 좋습니다. 그것들을 대신 view또는 vi -R대신 에 파이프로 연결하십시오 .

당신이 실제로 그것을 편집 할 수있는 그런 큰 파일을 열 경우, 고려 sed하거나 awk또는 다른 프로그래밍 방법.

서버에 ossec 에이전트가 설치되어 있는지 확인하십시오. 또는 일부 프로세스에서 삭제 된 로그 파일을 사용하고 있습니다. 내 옛날에는 오스 섹 요원이었습니다.

/ lost + found를 확인하십시오. 시스템 (centos 7)이 있고 / lost + found의 일부 파일이 모든 공간을 차지했습니다.