우리는 BBB 기반 맞춤형 보드를 가지고 있으며, 256MB RAM과 4GB 또는 eMMC를 갖추고 있습니다. 우리는 Linux-3.12를 사용하고 있으며 eMMC에는 ext4 파티션이 있습니다.
주기적으로 실행되어 파일 시스템 오류를 확인하는 스크립트를 작성 중입니다. 파티션이 마운트되지 않은 경우 e2fsck를 사용하여 오류를 수정하려고 합니다. 처음에는 파일 시스템 파티션의 오류를 확인하는 데
사용했습니다 . 그러나 위 명령은 파티션이 마운트되고 파티션에 파일이 생성될 때 잘못된 결과를 제공하기 시작했습니다.e2fsck -n /dev/mmcblk0pN (N is partition number)
이제 파일 시스템 오류를 확인하기 위한 대안이 필요했습니다.
옵션 중 하나는 tune2fs -l해당 파티션 검사에서 Filesystem state필드에 대한 명령을 사용하는 것입니다.
이제 이 필드가 파일 시스템 오류를 검사하는 데 신뢰할 수 있는지 확실하지 않습니다. 그리고 이 필드는 어떤 값을 가질 수 있나요? 나는 그 값 clean을 보았지만 매뉴얼 페이지에서 더 많은 정보를 얻지 못했습니다.clean with errorsnot clean
그렇다면 tune2fs -l /dev/mmcblk0pN | grep “Filesystem state” | grep “error”파일 시스템 오류를 안정적으로 감지할 수 있습니까? 파티션의 파일 시스템 오류를 확인하는 다른 더 좋은 옵션이 있습니까?
어떤 제안/포인터/정보가 있습니까?
답변1
"Tune2fs -l"은 커널이 실행되는 동안 파일 시스템 손상 문제를 발견했는지 알려줍니다. 예를 들어, ext4에 파일 삭제를 요청했는데 ext4가 해당 파일의 일부 블록이 이미 할당 취소된 것으로 표시된 것을 발견했다면 이는 할당 비트맵이 손상되었음을 의미합니다. 할당 비트맵은 ext4가 이를 발견했을 때 이미 손상되어 있었습니다. 실제로 며칠 또는 몇 주 동안 손상되었을 수 있으며 새 파일을 작성했다면 ext4가 이전 파일에 사용되었던 새 파일에 블록을 할당했을 가능성이 있으며 사용자는 데이터를 손실했을 수 있습니다. 결과.
파일 시스템이 일관성이 있는지 또는 어느 정도 손상이 있을 수 있는지 확실하게 말할 수 있는 유일한 방법은 e2fsck를 실행하는 것입니다. 이렇게 하려면 파일 시스템을 마운트 해제하거나 읽기 전용 스냅샷을 생성해야 합니다. (LVM을 사용하는 경우 읽기 전용 스냅샷을 생성하고 읽기 전용 스냅샷을 확인한 후 파일 시스템이 손상된 것으로 확인되면 시스템을 재부팅하고 e2fsck에서 파일 시스템을 수정하도록 할 수 있습니다. 또는 시스템 관리자에게 이메일을 보내 파일 시스템을 수정하기 위한 가동 중지 시간을 예약하세요.)
즉, 파일 시스템이 손상된 경우 가장 일반적인 경우는 하드웨어 문제 때문일 가능성이 높습니다. 업스트림뿐만 아니라 안정적인 커널에 대해 주기적으로 회귀 테스트를 실행하고 오랫동안 fs 손상 문제가 발생하지 않았지만 커널 버그 때문일 수도 있습니다. 장치 드라이버에 메모리 손상 버그가 있을 수 있으며 (a) 장치 드라이버가 업스트림이 아니고 하드웨어 공급업체가 적절한 품질 관리를 수행하지 않았거나 (b) 버그가 업스트림에서 수정되었을 수 있습니다. , 심지어 최신 안정 커널로 푸시되었지만 장치 커널이 안정 커널 시리즈에서 업데이트를 받지 않았습니다.
커널이 명백히 잘못된 것으로 인해 파일 시스템이 손상되었는지 확인하려는 경우 dmesg 또는 /var/log/messages를 긁어낼 필요는 없습니다. /sys/fs/ext4//first_error_time 파일을 읽어볼 수도 있습니다. 해당 파일에 0이 아닌 값이 포함되어 있으면 커널이 파일 시스템 손상을 감지한 시간(Unix epoch 사용)을 알려줍니다. 해당 디렉토리에 있는errors_count 파일은 얼마나 많은 파일 시스템 손상이 감지되었는지 알려줍니다(단, 시스템이 동일한 문제를 계속해서 반복해서 발생하는 것일 수도 있습니다). 또한 흥미로운 점은 시스템이 커널에 의해 감지된 파일 시스템 오류를 어떻게 처리하는지 테스트하려는 경우 Trigger_fs_error 파일에 문자열을 작성해 볼 수 있다는 것입니다. --- 예: echo "test error" > /sys/fs/ ext4/sda1/trigger_fs_error"
마지막으로 tune2fs에서 설정할 수 있는 오류 동작 노브를 살펴보시기 바랍니다. 파일 시스템 손상 문제가 감지된 후 더 많은 손상이 발생하지 않도록 하고 싶다면 문제가 발견되었을 때 읽기 전용으로 다시 마운트하도록 파일 시스템을 구성할 수도 있습니다. --- 또는 강제로 재부팅하여 부팅 시퀀스 중에 e2fsck를 실행하여 사용자 데이터가 손상되거나 손실되기 전에 문제를 해결할 수도 있습니다.