내 디스크 드라이브 /dev/sdc가 꽉 찼습니다(아래 참조). 어쨌든 디스크 공간을 모두 소모하는 이유를 해결할 수 있는 방법이 있습니까?
실행해 보았지만 du -d -h 1올바른 명령이 아닌 것 같습니다.
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdc 14G 13G 0 100% / <--- here
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 174M 1.7G 10% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/sda1 488M 132M 321M 30% /boot
/dev/sdd 99G 25G 73G 26% /data
tmpfs 378M 0 378M 0% /run/user/0
기타 로그 출력:
$ du -h -d 1
52K ./tmp
131M ./boot
24M ./opt
4.0K ./mnt
34M ./etc
1.6G ./root
0 ./sys
44K ./sysadmin
du: cannot access './proc/58885/task/58885/fd/4': No such file or directory
du: cannot access './proc/58885/task/58885/fdinfo/4': No such file or directory
du: cannot access './proc/58885/fd/4': No such file or directory
du: cannot access './proc/58885/fdinfo/4': No such file or directory
0 ./proc
16K ./lost+found
0 ./dev
25G ./data
4.0K ./media
32K ./home
182M ./run
2.6G ./usr
921M ./var
4.0K ./srv
31G .
$ du -ahx --threshold=1G
1.2G ./root/ffmpeg_sources
1.6G ./root
2.6G ./usr
5.2G
답변1
예상치 못한 디스크 사용량을 식별하려면 여러 가지 접근 방식을 취해야 합니다.
디스크 사용량 숨기기
몇몇 사람들이 그것을 제안했거나
du -xhs /*그 변형을 제안했습니다. 이것은 좋은 출발점이지만 마운트 지점 아래를 보지는 않습니다. (실수로 데이터를 쓴 다음 거기에 파일 시스템을 마운트할 수 있습니다.) 와일드카드에는 포함성이 필요하므로 이 명령은 루트가 아닌 파일 시스템에 대해서도 보고합니다.이러한 문제는 다음을 통해 해결할 수 있습니다.바인드 마운트.
mkdir -p /mnt/root mount --bind / /mnt/root shopt -s dotglob du -hs /mnt/root/*그러면 루트 파일 시스템이 마운트
/mnt/root되고 모든 최상위 디렉터리(및 파일)의 요약이 보고됩니다. 기본 마운트와 달리/고려해야 할(그리고 피해야 할) 보조 마운트 파일 시스템이 없습니다.삭제된 파일
삭제되었지만 아직 열려 있는 파일은 닫힐 때까지 디스크 할당을 유지합니다. 이것은 다른 답변에서 다루어졌으므로 완전성을 위해 여기서 언급하겠습니다.
lsof | grep deleted
답변2
내가 한 첫 번째 일은 드라이브에 무엇이 들어 있는지 확인하는 것이었습니다. 설치에 따라 /home, /usr 또는 /var(/var이 로그를 유지하며 프로세스가 로그에 너무 많은 오류 메시지를 생성하는 것일 수 있음) 디스크 사용량을 확인하고 일단 디렉터리가 차지하는 부분을 찾으면 공간이 있으면 드롭다운하여 하위 디렉터리를 찾습니다.
일단 그 사실을 파악하고 나면 문제가 문제인지(너무 많은 비디오를 다운로드하여 전체 드라이브를 채우는 경우) 또는 실행 중인 로그, 데이터 파일 등을 생성하는 프로세스인지 확인할 수 있습니다. ...
문제가 귀하에 의해 발생한 것이 아니라 과정에 의한 것이라면 이전 단계에서 수집한 정보를 활용하여 문제를 파악해야 하며 이제 문제를 해결할 수 있을 수도 있습니다.
편집: 내 대답을 되돌아보면 중요한 점을 놓쳤다는 것을 알 수 있습니다. 마운트 지점인 디렉터리에 파일을 만든 다음 해당 디렉터리에 무언가를 설치하면 해당 파일을 볼 수 없습니다. 해당 디렉터리에서 장치를 마운트 해제합니다. 그 안에 파일이 있다는 것을 모를 수도 있으므로 장치를 마운트 해제하고 해당 디렉터리에 파일이 있는지 확인해야 할 수도 있습니다.
답변3
드라이브가 가득 차는데 눈에 띄는 증거가 보이지 않는 이유 중 하나는 du개인 파일과 관련이 있습니다. 프로세스는 쓰기 위해 파일을 열고 쓰기를 시작한 다음 디렉터리에서 파일을 삭제할 수 있습니다. 이로 인해 프로세스가 계속 쓸 수 있는 열린 파일이 남게 되며, 이 파일은 여전히 디스크 공간을 소비하지만 파일 시스템을 탐색하여 발견할 수 없습니다. 어리석게 들리지만 다른 프로세스에 노출되기를 원하지 않는 민감한 정보를 위한 임시 저장소를 할당하는 데 유용합니다.
다른 프로그램도 쓰기 위해 파일을 연 프로그램이 해당 파일에 대해 알지 못한 채 해당 파일을 삭제할 수 있습니다. 때때로 사용자는 syslogd소유자 프로세스(예:)에 의해 아직 열려 있는 로그 파일(또는 기타 파일)을 삭제하여 공간을 확보하려고 합니다. 결과적으로 파일은 계속해서 공간을 차지하거나 커집니다.더 세게찾다.
그러한 파일을 찾으려면 커널의 열린 파일 목록을 살펴봐야 합니다. lsof이 목적을 위해 선택한 도구입니다. 열려 있는 모든 파일과 현재 커널에서 읽거나 쓰고 있는 파일의 오프셋을 표시합니다.
다음은 도움이 될 수 있는 명령입니다.
lsof -o /dev/sdc | grep deleted
이것이 무엇을 하는지 이해해 봅시다:
lsof열린 파일 나열-o인용하다언제나파일 오프셋 표시/dev/sdc결과를 /dev/sdc 블록 장치의 파일로 제한
파일이 삭제되면 lsof해당 파일이 있던 위치 뒤의 줄 끝 부분에 나타납니다. 그걸 찾아보세요.(deleted)grep deleted
이러한 파일 중 일부는 정상일 수 있습니다. 그러나 출력의 열 7에는 오프셋이 표시됩니다 0t. 오프셋도 많이 삭제되는 경우 볼 수 없을 만큼 많은 디스크 공간을 소비하고 있습니다.
이 공간을 비우려면 프로세스를 종료해야 합니다. (프로세스에 따라 다시 시작해야 할 수도 있습니다.) 곧 디스크 공간이 늘어나는 것을 볼 수 있습니다.