우리는 BBB 기반의 커스텀 보드를 가지고 있으며 256MB 램과 4GB 또는 eMMC를 가지고 있습니다.
우리는 Linux-3.12를 사용하고 있습니다. eMMC에는 ext4 파티션이 있습니다.
주기적으로 실행되고 파일 시스템 오류를 검사하는 스크립트를 작성 중이며 파티션이 마운트되지 않은 경우 e2fsck를 사용하여 오류를 수정하려고합니다.
처음에 나는 e2fsck -n /dev/mmcblk0pN (N is partition number) 파일 시스템 파티션의 오류를 검사합니다.
그러나 위의 명령은 파티션이 마운트되고 파일이 파티션에 만들어 질 때 잘못된 결과를 제공하기 시작했습니다.
이제 파일 시스템 오류를 검사 할 대안이 필요했습니다.
하나는 옵션을 사용하는 것입니다. tune2fs -l 해당 파티션에서 명령이 다음을 확인합니다. Filesystem state 들.
이 필드가 파일 시스템 오류를 검사하는 데 신뢰할 수 있는지 여부는 확실하지 않습니다. 이 필드가 가질 수있는 가능한 값은 무엇입니까?
나는 그 가치를 보았다. clean, clean with errors 과 not clean 그러나 나는 man 페이지에서 더 많은 정보를 얻지 못했다.
그래서,
~이다. tune2fs -l /dev/mmcblk0pN | grep “Filesystem state” | grep “error” 신뢰할 수있는 파일 시스템 오류를 감지? 파티션의 파일 시스템 오류를 검사하는 다른 더 좋은 옵션은 무엇입니까?
어떤 제안 / 포인터 / 정보?
답변
“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를 실행하여 (더 많은) 사용자 데이터가 손상되거나 손실되기 전에 문제를 해결할 수 있습니다.