상황은 다음과 같습니다. 저는 (아주 오래된) 파일 시스템을 가지고 있습니다. 이는 2006년에 생성되었습니다. ext2로 시작한 다음 ext3, ext4, 64비트 ext4로 이동했습니다. 최근에 Metadata_csum을 활성화했는데 문제가 없었습니다. 샘플링하면 가장 오래된 데이터도 올바르게 검색되는 것 같습니다. 파일 시스템의 fsck 루틴은 생성 이후 비활성화되었습니다. HBA 케이블 호핑으로 인해 기본 mdraid에 약간의 OOPS가 발생한 후 FS를 재조립하고 현재 설치하기 전에 fscking 중입니다. 한 가지 잠재적인 문제는 mdraid 재구성에 약간 더 많은 OOPS가 있고 볼륨에 (올바른 이전) 메타데이터 0.90으로 재할당되기 전에 메타데이터 1.2가 할당되었다는 것입니다. 결과적으로 각 기본 파티션의 시작 부분부터 약 300~4096바이트를 덮어씁니다. 디스크당 하나라고 가정하면 총 12개의 블록입니다. 이를 염두에 두고 fscking을 수행합니다. 물론 첫 번째 슈퍼블록은 손상되었지만 fsck는 백업 슈퍼블록으로 올바르게 이동하여 행복하게 제거됩니다. 버그가 엄청 많은 것 빼고는 딱히 버그는 없는 것 같습니다 Inode nnnnn passes checks, but checksum does not match inode. Fix? no. 매우 큰 숫자란 2.6*10^9 inode가 있는 파일 시스템에서 거의 10^6을 의미합니다. 유일한 다른 오류가 20개 미만이라는 점을 감안할 때 Inode nnnn contains garbage. Clear? no"이전" inode의 메타데이터(즉, 기능이 활성화된 후 기록되지 않은 메타데이터)가 단순히 잘못된 것일 수도 있습니까? 2010년부터 2013년까지 이에 대한 많은 논의가 있었다가 사라졌다. 이 경우 가장 좋은 방법은 해당 기능을 제거하고 다른 버그를 수정한 다음 다시 추가하는 것입니까? 40TB 볼륨인데 무슨 이유인지(TM) 마지막 백업 이후 약 18개월이 지났습니다.
참고로 시스템은 현재 최신 업데이트가 포함된 Debian 11 amd64를 실행하고 있습니다.