저는 OpenBox WM이 포함된 데비안 변형인 Crunchbang을 실행하고 있습니다. thunar 파일 관리자를 탐색하고 del 키를 눌러 많은 파일을 삭제했습니다. 그들은 시야에서 사라집니다. 그런 다음 ~/.local/share/Trash/files/로 이동하여 거기에서 삭제합니다. 그러나 파일 시스템은 여전히 여유 공간을 보고하지 않습니다.
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb5 61G 57G 371M 100% /
답변1
루트 파티션에서 무엇이 공간을 차지하고 있는지 추적하려고 시도하면서 비슷한 문제가 발생한 적이 있었지만 디스크 사용량 분석기 Baobab은 이를 보고하지 않았습니다. 마지막으로 루트 사용자의 휴지통 폴더에서 이 파일을 찾았습니다 /root/.local/share/Trash. Baobab 및 기타 유틸리티가 이러한 파일을 표시하지 않는 이유는 루트가 아닌 사용자로 해당 파일을 실행하고 있고 /root폴더를 읽는 데 필요한 권한이 없기 때문입니다 . 빠른 su를 사용하면 필요한 디렉토리와 rm *파일을 입력할 수 있습니다.
답변2
한 가지 가능한 이유는 ext2/3/4 및 기타 "Unix 파일 시스템"이 루트를 위해 일정량의 공간을 예약하기 때문입니다. 기본값은 5%라고 생각합니다. 이렇게 하면 시스템이 파일 시스템이 꽉 찼다고 보고하고 루트가 아닌 일반 사용자가 아무것도 쓰지 못하도록 거부하더라도 루트 사용자와 루트 실행 프로세스는 여전히 작동할 수 있는 공간을 갖습니다.
이는 일부 파일 시스템에 적합합니다. 예를 들어 /(루트), /var, 하나의 파일 시스템에 모든 것이 있는 경우... /home 및 /usr 파일 시스템에는 덜 이상적일 수 있습니다. 예약된 공간이 더 적어야 합니다(아마도 1% 또는 없음).
그럼에도 불구하고 df"0바이트 사용 가능", "100% 사용됨"과 같은 명령이 보고되면포함되지이 5%는 루트용으로 예약되어 있습니다! 따라서 일반 사용자가 차단되는 동안 루트 사용자와 루트로 실행 중인 프로세스는 계속해서 쓰기를 할 수 있습니다. 겉으로는 파티션을 100% 이상 채우는 것처럼 보입니다.
이는 디스크가 생각만큼 꽉 차 있지 않다는 것을 의미합니다. 그러나 삭제한 파일 중 일부가 100% 전체 제한 파일을 초과하여 기록되었다는 이유만으로 파일 삭제가 생각만큼 큰 영향을 미치지 않을 수도 있습니다. 그래서 나중에 표시되지 않습니다 df.
따라서 디스크에 100GB의 유효 공간이 있으면 df95GB로 표시됩니다. 그러나 95GB를 채우고 df디스크가 꽉 찼다는 메시지가 표시되고 시스템이 일반 사용자 쓰기를 거부하면 루트는 여전히 5GB를 더 쓸 수 있습니다. 그런 다음 10GB 파일을 정리하고 삭제하면 df루트용으로 예약된 5GB가 무시되고 5GB(10GB 아님)만 여유 공간으로 나타납니다. 따라서 루트용으로 예약된 공간 중 일부를 사용했다고 가정하므로 7GB를 제거하면 예약된 한도 아래에 378MB만 남게 됩니다.
이를 사용하여 tune2fs루트를 위해 예약할 공간의 양을 변경할 수 있습니다. 일부(아마도 5% 이하)여야 합니다. mke2fs처음 파일 시스템을 생성(파티션 포맷)할 때 예약할 공간(백분율 또는 바이트 단위)을 설정할 수 있는 옵션도 있습니다 . 디스크가 더 작으면 5%가 더 합리적입니다. 500GB를 초과하는 디스크의 경우 5%는 약간 큰 의미가 있습니다.
답변3
다음 명령을 실행하여 각 디렉터리가 차지하는 디스크 공간을 확인할 수 있습니다.
du -hc --max-depth=1
현재 있는 디렉터리의 크기가 이상한 경우 이 명령을 실행하고 더 이상 필요하지 않은 파일을 삭제하세요.
/흥미로운 내용이 발견되지 않으면 디렉터리에서 명령을 실행하세요. 필요한 경우 출력을 게시합니다.
Bleachbit을 사용할 수도 있습니다. 시도해 보세요.표백 비트
답변4
글쎄, 시도해 볼 가치가 있으므로 여기에 게시해야겠다고 생각했습니다.
# find /root/.local/share -name '*.trashinfo'
이것들은 불쾌한 작은 동물입니다. 개인적으로 okteta콘솔 모드(16진수 편집기)에서 시작했을 때 이러한 문제가 발생했으며 kio_trash내 터미널은 메시지에 대한 쓸모없는 "정보"로 가득 차 있었습니다 파일을 계속 찾는 것입니다 . 디렉토리 를 완전히 정리하자 Linux 시스템에 평화가 돌아왔습니다. :) 이 쓰레기를 발명한 사람은 누구나 테이저건을 받아야 합니다.cannot stat: ...$HOME/.local/share/Trash/info.trashinfoinfo