512MB의 RAM과 많은 외부 저장소가 연결된 오래된 데비안 리눅스 상자 (에칭 실행)를 돌 봅니다. 하나의 ext3 파일 시스템의 크기는 2.7TB이며 fsck는 다음과 같은 오류와 함께 메모리가 부족하여 확인할 수 없습니다.
디렉토리 블록 배열 할당 오류 : 메모리 할당 실패 e2fsck : 중단
4GB 스왑 파티션을 추가 했는데도 아직 완료되지 않았지만 이것은 32 비트 커널이므로 더 이상 추가해도 도움이 될 것으로 기대하지 않습니다.
64 비트 커널로 부팅하는 것 외에도 fsck가 검사를 완료하도록하는 다른 방법이 있습니까?
답변
64 비트 커널과 대량의 RAM은 fsck가 훌륭하고 빠르게 완료되도록합니다. 또는 e2fsck에는 RAM 대신 디렉토리에 모든 중간 결과를 저장하도록 지시하는 옵션이 있습니다.이 옵션은 엄청나게 도움이됩니다. /etc/e2fsck.conf다음 내용으로 작성하십시오 .
[scratch_files]
directory = /var/cache/e2fsck
(그리고 분명히, 디렉토리가 존재하고 충분한 여유 공간이 몇 GB 인 파티션에 있는지 확인하십시오). e2fsck는 SLLOOOOWWWWWWW를 실행하지만 최소한 완료됩니다.
물론 이것은 루트 FS에서는 작동하지 않지만 스왑이 있으면 어쨌든 루트 FS를 마운트 한 것입니다.
답변
나는 울퉁불퉁 한 것을 제안하려고 노력했다. 나처럼 e2fsck에서이 새로운 기능을 본 적이 없다면 유용 할 수있는 몇 가지 세부 사항이 있습니다.
e2fsck의 “scratch_files”구성 옵션이 버전 1.40.x 기간 중에 언젠가 사용 가능해졌습니다. (이 경우이 기능을 사용하려면 최신 데비안 배포판으로 업그레이드해야했습니다.)
제안 된 “directory = / var / cache / e2fsk”옵션뿐만 아니라 스크래치 파일 스토리지 사용 방법을 미세 조정하기위한 추가 구성 옵션이 있습니다. 파일 시스템에 많은 수의 파일이 있지만 그렇게 많은 수의 디렉토리가 없기 때문에 “dirinfo = false”를 사용했습니다. 상황이 반대로 바뀌면 “icount”옵션이 적합합니다. 이 옵션은 모두 e2fsck.conf 매뉴얼 페이지에 설명되어 있습니다.
BTW, 테드 T’so은 이러한 옵션에 대해 쓴 이 스레드 .
e2fsck가 Ted가 예측 한 것보다 훨씬 느리게 실행되고 있음을 알았습니다. CPU 사용률은 대부분 99.9 %로 매우 오래된 프로세서에서 실행되었으므로 메모리 대신 디스크에 이러한 데이터 구조를 저장하는 것이 속도 저하의 주요 원인이 아님을 나타냅니다. 파일 시스템에 저장된 내용과 관련하여 e2fsck가 특히 느려질 수 있습니다. 결국, 나는 파일 시스템 검사를 포기했다. 파일 시스템은 점검 대상 이었지만 오류가 없었으므로 (내가 아는 한) 오류가 없었으므로 일주일 동안 중단 될 수있는보다 편리한 시간에 파일 시스템을 점검하도록하겠습니다.