"일반적인" /mnt/build_tmp인 /dev/xvdb에 스토리지가 마운트된 Amazon AWS 인스턴스가 있습니다. 약 70GB(정확히 66,946,696kB)이다. 글을 쓰려고 보니 꽉 찬 것 같았습니다. 그럴 것 같지 않아서 확인해보니 ('du'에 따르면) 약 11GB의 파일이 있었지만 /mnt(/mnt/build_tmp만 포함)는 ('df'에 따르면) 100% 가득 찼습니다. 한 파일(5.5GB의 큰 tar 파일)을 제외하고 모든 파일(약 6GB 상당)을 삭제했는데 이제 약 6GB의 여유 공간이 생겼습니다. 정확히 현재 상황은 이렇습니다.
ubuntu@ip-172-31-60-67:/mnt$ df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 8115168 6083076 1596816 80% /
none 4 0 4 0% /sys/fs/cgroup
udev 7689964 12 7689952 1% /dev
tmpfs 1540092 780 1539312 1% /run
none 5120 0 5120 0% /run/lock
none 7700456 72 7700384 1% /run/shm
none 102400 8 102392 1% /run/user
/dev/xvdb 66946696 57365136 6174200 91% /mnt
ubuntu@ip-172-31-60-67:/mnt$ du
5773532 ./build_tmp
du: cannot read directory ‘./lost+found’: Permission denied
16 ./lost+found
5773552 .
ubuntu@ip-172-31-60-67:/mnt$ ls
build_tmp/ lost+found/
ubuntu@ip-172-31-60-67:/mnt$ ll build_tmp/
total 5.6G
drwxr-xr-x 2 ubuntu 4.0K Sep 18 18:33 ./
drwxr-xr-x 4 root 4.0K Aug 25 18:43 ../
-rw-rw-r-- 1 ubuntu 5.6G Sep 17 00:38 archive.tar.gz
누구든지 이것을 설명할 수 있나요? 나는 전에 이런 것을 본 적이 없습니다. 아무래도 AWS의 결과인 것 같지만 좀 더 일반적인 것일 수도 있습니다.
어쨌든 디스크에서 누락된 50GB 이상의 공간을 복구해야 합니다.
[ps 나는 이미 "df가 du와 다른 이유"라는 수퍼유저 질문을 확인했는데, 내 문제와 관련이 없는 것 같았습니다.]
답변1
이는 여기에 설명된 문제의 변형으로 밝혀졌습니다.
거기에 설명된 해결책은 이 문제에 대한 해결책이었습니다.
삭제된 파일이 프로세스에 의해 여전히 열려 있는 경우 프로세스가 파일을 닫을 때까지(또는 종료될 때까지) 공간은 회수되지 않습니다. 파일을 열어둔 프로세스를 식별할 수 없는 경우 재부팅하면 실행 중인 모든 프로세스가 닫히고 열려 있는 모든 파일이 닫히므로 도움이 됩니다.
열린 프로세스를 찾아서 종료하면 공간이 복구되었습니다.