"Tune2fs -l"은 커널이 실행 중일 때 파일 시스템 손상 문제를 발견했는지 알려줍니다. 예를 들어, ext4에 파일 삭제를 요청한 경우 ext4가 해당 파일의 일부 블록이 이미 할당 해제 된 것으로 표시되면 할당 비트 맵이 손상되었음을 나타냅니다. allocaiton 비트 맵은 ext4가 발견했을 때 이미 손상되었음을 유의하십시오. 사실, 며칠 또는 몇 주 동안 손상되었을 수 있었고 새로운 파일을 작성했다면 ext4가 이전 파일에 사용 된 새 파일에 대한 블록을 할당했을 가능성이 있으며 사용자가 데이터를 잃어버린 것처럼 보일 수 있습니다 결과.
확실하게 파일 시스템이 일관성이 있는지 또는 부패가 어느 정도 있는지 여부를 확실하게 밝힐 수있는 유일한 방법은 e2fsck를 실행하는 것입니다. 이렇게하려면 파일 시스템을 마운트 해제하거나 읽기 전용 스냅 샷을 작성해야합니다. LVM을 사용하는 경우 읽기 전용 스냅 샷을 만들고 읽기 전용 스냅 샷을 확인한 다음 파일 시스템이 손상된 것으로 확인되면 시스템을 재부팅하고 e2fsck에서 파일 시스템을 수정하도록 할 수 있습니다. 시스템 관리자에게 전자 메일을 보내 파일 시스템을 수정하기위한 가동 중지 시간을 예약하십시오.)
이 모든 것은 파일 시스템이 손상된 경우 하드웨어 문제가 가장 흔한 경우라고 할 수 있습니다. 업스트림이 아닌 안정적인 커널에 대해 회귀 테스트를 주기적으로 실행하기는하지만 커널 버그가 원인 일 수 있습니다. 오랫동안 fs 손상 문제가 없었습니다. 장치 드라이버에 메모리 손상 버그가있을 수 있으며 (a) 장치 드라이버가 업스트림이 아니며 하드웨어 공급 업체가 적절한 품질 제어를 수행하지 않았거나 (b) 버그가 업스트림에서 수정 된 것일 수 있습니다 심지어는 최신의 안정적인 커널로 밀어 넣었지만, 장치 커널은 안정된 커널 시리즈에서 업데이트를받지 못했습니다.
커널이 뭔가 잘못되었을 때 파일 시스템이 손상된 것으로 판명되면 dmesg 또는 / var / log / messages를 긁어 낼 필요가 없습니다. / sys / fs / ext4 // first_error_time 파일을 읽어 볼 수도 있습니다. 이 파일에 0이 아닌 값이 포함되어 있으면 커널에서 파일 시스템 손상을 감지 한 시간 (Unix 시대를 사용)을 알 수 있습니다. 그 디렉토리에있는 errors_count 파일은 얼마나 많은 파일 시스템 훼손이 발견되었는지를 알려줍니다 (하지만 시스템은 동일한 문제를 반복해서 반복해서 반복 할 수 있습니다). 또한 커널에서 파일 시스템 오류를 감지하는 방법을 테스트하려는 경우 trigger_fs_error 파일에 문자열을 쓰도록 시도 할 수 있습니다 (예 : echo "test error"& gt; / sys / fs / ext4 / sda1 / trigger_fs_error "
마지막으로 tune2fs에서 설정할 수있는 오류 비헤이비어 노브를 살펴보십시오. 파일 시스템 손상 문제가 감지 된 후에 더 많은 피해가 발생하지 않도록하려면 문제가 발견되었을 때 읽기 전용으로 다시 마운트하도록 파일 시스템을 구성하려고합니다. 또는 단지 재부팅을 강요하므로 부팅 시퀀스 중에 e2fsck를 실행하여 (더 많은) 사용자 데이터가 손상되거나 손실되기 전에 문제를 해결할 수 있습니다.
fsck부팅 할 때 확인하십시오. 우리는 가지고 있지 않다.filesystem_check데몬 같은systemd이제 우리가 할 수있는 일은 스크립트를 작성하여 시작시 및 정상적인 시스템 실행 중에 주기적으로 실행하는 것입니다. 부팅 스크립트는 모든 ext4 파티션을 검사하고 다음을 사용하여 오류를 수정합니다.e2fsck -y( Or e2fsck -p), 필요한 경우 다시 부팅하십시오. 정상적인 작동에서는 똑같은 일을하지만 오류를 정정하지는 않겠지 만이를보고합니다.