한때 수백만 개의 파일이 있었던 폴더의 디렉터리를 나열하는 데 시간이 오래 걸립니다.

한때 수백만 개의 파일이 있었던 폴더의 디렉터리를 나열하는 데 시간이 오래 걸립니다.

파일 시스템은 ext4이고 시스템은 몇 년 동안 재부팅되지 않았으며 지금은 재부팅하고 싶지 않습니다.

한때 수백만 개의 작은 파일(크기 2-3kb)이 포함된 폴더가 있었습니다. 이로 인해 시스템이 거의 손상될 뻔했기 때문에 너무 많은 파일을 생성하는 코드를 수정하고 디렉토리의 모든 파일을 삭제하는 크론태스크를 작성했습니다( rm작동하지 않았기 때문에).

처음에는 모든 것이 순조롭게 진행되며, 입력하면 ls4~5개의 남은 파일이 포함된 전체 목록이 표시됩니다.

그런데 다음날 입력을 해보니 ls시스템이 명령을 실행하는 데 오랜 시간이 걸리고(몇 분 정도 소요) 시스템 부하가 초과되었습니다.20겁이 난다.

기본적으로 몇 달 동안 그랬습니다. 하루 만에 처음으로 이 작업을 수행했을 때 ls시스템 속도가 느려지고 결국 하위 폴더가 없는 5개 파일 목록이 반환되었습니다.

나는 이것이 일부 ext4 캐시라고 생각합니다. 다양한 명령을 실행해 보았지만 소용이 없었습니다.

ext4가 캐시를 지우도록 강제로 할 수 있는 다른 방법이 있나요?

시스템이 RAID 1 모드에서 실행 중입니다. Run은 cat /proc/mdstat두 드라이브가 모두 완벽하게 작동하고 동기화되어 있음을 보여줍니다. smartctl드라이브도 잘 돌아가고 있다고 하더군요. hdparm은 다음을 반환합니다.

hdparm -tT /dev/sda1
/dev/sda1:
Timing cached reads:   19238 MB in  2.00 seconds = 9629.50 MB/sec
Timing buffered disk reads: 316 MB in  3.01 seconds = 104.92 MB/sec

답변1

이는 Ext 파일 시스템 제품군의 알려진 문제입니다.항목을 삭제한 후에도 항목 수가 많은 디렉터리의 크기가 줄어들지 않는 이유는 무엇입니까?더 알아보기.

이 문제를 해결하는 유일한 방법은 디렉터리를 다시 만드는 것입니다. 먼저 기존 디렉터리의 이름을 바꿉니다(이렇게 하면 프로세스가 해당 디렉터리에서 파일을 열려고 할 때 문제가 발생하지 않습니다).

mv brokendir repairdir/

그런 다음 새 디렉터리를 만듭니다(아직 이전 이름을 사용하지 않음).

mkdir newdir

손상된 디렉터리의 모든 내용을 새 디렉터리로 이동합니다.

mv repairdir/* newdir/
mv repairdir/.[!.]* newdir/
mv repairdir/..?* newdir/

(세 개의 개별 명령으로 구성되어 있어 그 중 하나가 실패하면 어떤 일이 발생하는지 정확히 알 수 있습니다.예를 들어이동할 숨겨진 파일이 없는 경우).

새 디렉터리의 메타데이터가 원래 디렉터리와 동일한지 확인하고 싶을 수 있습니다. 특히 GNU coreutils를 사용하는 경우에는 다음과 같은 방법으로 수행할 수 있습니다( repairdir비어 있는 경우).

cp -aT repairdir newdir

마지막으로 모든 것을 뒤로 이동하고 이전 디렉터리를 삭제합니다.

mv newdir brokendir/
rmdir repairdir

관련 정보