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가 특히 느려질 수 있습니다. 결국, 나는 파일 시스템 검사를 포기했다. 파일 시스템은 점검 대상 이었지만 오류가 없었으므로 (내가 아는 한) 오류가 없었으므로 일주일 동안 중단 될 수있는보다 편리한 시간에 파일 시스템을 점검하도록하겠습니다.