요약:
- 내가 시도한 모든 도구는 이 ext4 파티션에서 많은 수의 inode가 사용되고 있음을 확인합니다.
- 내가 시도한 모든 도구에는 파티션에 파일이 표시되지 않습니다.
- 그렇지 않다파일은 계속 열려 있습니다.이것은 아니다오버레이 설치
매우 긴 이야기:
단일 ext4 파티션이 있는 SSD가 있습니다. 이 드라이브는 카메라의 비디오 클립을 지속적으로 저장하는 데 사용되며 cron 작업은 가장 오래된 클립을 주기적으로 삭제합니다(C 애플리케이션에서는 delete them을 호출하여 remove()). 잠시 후 누군가가 5일 분량의 비디오를 백업해야 했는데 거의 백업되지 않았으며 드라이브가 거의 꽉 찼다는 사실을 누군가가 알아차렸습니다.
그것을 보고 순진하게 삭제를 시도했지만 lost+found드라이브는 여전히 가득 차 있었습니다. 그래서 삭제했어요모든 것( rm -rf *), 그러나 df -i91230 inode가 사용 중이라고 알려주고 아무것도 표시하지 않습니다 ls.du
e2fsck -fv수정된 오류는 발견되지 않았으며(재작성 제외 lost+found) dumpe2fs양측 은 사용된 inode 수 tune2fs -l에 동의했습니다 . 슈퍼블록의 백업을 여러 번 df -i시도했지만 e2fsck -b아무런 차이가 없는 것 같습니다.
baobab요약 보기와 동일한 사용 공간이 표시되지만 df공간이 사용되는 위치를 확인하기 위해 파티션을 클릭하면 lost+found빈 디렉터리에서 사용되는 4.1kB만 표시됩니다.
문제는아니요삭제된 파일 핸들은 여전히 열려 있습니다. 아무것도 열려 있지 않습니다. 저는 파티션을 여러 번 마운트하고 마운트 해제했으며 심지어 드라이브를 꺼내서 완전히 다른 시스템에 넣었습니다.
파티션을 다시 포맷하고 다시 시작할 수 있다는 것을 알고 있지만 여기서 무슨 일이 일어나고 있는지, 그리고 이 문제를 해결할 "올바른" 방법이 있는지 정말로 알고 싶습니다. 해당 inode에 대한 파일을 다시 가져오는지는 상관하지 않습니다. 모든 공간을 사용하지 않도록 제대로 삭제하지 마십시오.
편집: 실행하면 다른 사용자가 보고한 사용 공간 dump과 대략 동일한 크기의 백업 파일이 생성됩니다 . 그런 다음 다른 드라이브로 df실행하면 명백히 잘못된 일련의 디렉터리가 생성되고( 동일한 구조를 반복하면서 더 깊은 수준으로 계속 진행됨) 다음과 같은 줄이 인쇄됩니다.restore/media/usb0/20150426/10/1_20150426_100125.264/20150426/10/1_20150426_100125.264/
expected next file 7823361, got 7610674
expected next file 7823361, got 7610675
(두 번째 숫자는 증가합니다. 터미널 버퍼를 훨씬 초과합니다.) 마지막으로:
cannot find directory inode 11
abort? [yn]
선택하면 n"디렉토리 노드 x를 찾을 수 없습니다"라는 메시지가 더 많이 표시되므로 중단합니다.
포기하고 다시는 일어나지 않을 이상한 파일 시스템 손상으로 처리하십시오.