Ext4 로그 손상으로 인해 파일을 삭제하고 FF로 덮어쓰면 전체 파일 시스템이 치명적인 손상을 입을 수 있나요?

6개월에 두 번 - 3개의 Ext4 디스크(그 중 하나는 약 1년 전 Seagate 디스크)에서 심각한 파일 시스템 손상을 겪었습니다. 무슨 일이 일어나는지는 많은 디렉토리에서 디렉토리 항목 목록이 잘리고 "."만 남는 것 같습니다. 및 ".."이며 많은 메타데이터 구조가 0xFF로 직접 덮어쓰여집니다. 즉, 블록은 4096번 반복되는 바이트 0xFF로만 구성됩니다. 저는 Ubuntu Mate, 18.04.3 LTS, 4.15.0-72-generic #81-Ubuntu SMP를 사용하고 있습니다.

약 6개월 전 첫 번째 사례에서는 정전이 발생한 머신에서 두 개의 디스크를 가져와 fscking 없이 다른 머신에 마운트했습니다. 디스크에 데이터를 쓰지 않았지만 읽기 전용으로 마운트하지 않았기 때문에 메타데이터가 기록되었을 수 있습니다. 결국 나는 둘 다에서 fsck를 실행했고 위의 손상이 발생했습니다. 특히, 슈퍼블록, 모든 백업 슈퍼블록, GDT의 모든 복사본 및 대부분의 inode 테이블을 0xFF 바이트로 덮어씁니다. 디스크에서 올바른 테이블 외부에 있는 inode 레코드와 디렉터리 파일을 검색하는 코드를 작성하여 대부분의 파일 시스템을 다시 하나로 모을 수 있었습니다. 한 디스크에서는 데이터의 약 절반을 복구했고 다른 디스크에서는 75%를 복구한 것으로 추정됩니다. 글쎄, 데이터 쓰기에 노출되지 않았음에도 불구하고 fsck를 실행하지 않고 RW 드라이브를 마운트할 만큼 부주의했습니다. 나는 이것을 너무 부주의하지 말라는 뼈아픈 교훈으로 받아들였다. 이상하게도 디스크의 잘못된 위치에서 일부 누락된 메타데이터를 발견했습니다. 이것이 내가 슈퍼블록과 꽤 많은 inode 테이블 항목을 복구할 수 있었던 방법입니다. 시스템이 패닉 상태에서 디스크의 여러 데이터 영역에 해당 내용을 쓴 것 같습니다. 체크섬으로 필터링한 결과, 이 스캔에서 부분 항목의 복사본 5-10개를 발견했습니다.

그런데 불과 며칠 전 비슷한 비리 사건이 또 발생했습니다(심각하지 않았으면 좋겠습니다). 내 데이터 디스크에 Ext4 파티션이 있지만(기본 옵션) 컴퓨터에 전원 문제가 있습니다. 기계가 계속 저절로 종료됩니다. 디스크는 1년밖에 안된 4TB Seagate 디스크입니다. 드디어 전원을 교체하고 설치하고 전원을 켜보니 데이터디스크가 손상된 것을 발견했습니다. 부팅을 여러 번(5?) 시도했는데 매번 비상/안전 모드로 들어갔습니다. 귀찮은 시작 화면은 시작을 시도하는 동안 무슨 일이 일어나고 있는지 나에게 숨깁니다. 데이터 디스크가 fstab에 나열되어 있지만 마운트할 수 없어 부팅에 실패했다는 사실을 마침내 깨달았습니다. fstab에서 삭제하면 시스템이 정상적으로 부팅됩니다. 디스크를 검사해 보니 손상된 것으로 나타났습니다. 정확히 말하면 블록 0의 모든 슈퍼블록은 0xFF입니다. 그러나 백업 하위 청크와 GDT는 모두 괜찮습니다. 첫 번째 inode 블록(inode 1-11)을 포함하여 사용된 inode 항목의 약 0.5%도 일반 0xFF로 덮어쓰여집니다(즉, 99.5%는 괜찮아 보입니다). 0xFF 적용 범위는 항상 블록 경계의 정수 블록입니다. 파일 시스템을 더 자세히 조사하기 시작했을 때 디렉터리 파일의 거의 모든 inode 항목이 한 번에 전체 블록인 0xFF로 덮어쓰여졌음을 발견했습니다. 따라서 0.5%의 inode만 사용 중이지만 손실되기 가장 불편한 0.5%입니다. 또한 여러 상위 수준 디렉터리 파일은 모든 항목(".", ".." 제외)이 제거된 것처럼 보입니다. 즉, ".." 항목의 rec_len 필드는 블록 끝까지 확장되고, 디렉토리 파일의 후속 블록은 첫 번째 항목의 inode 번호가 0으로 설정됩니다.

그래서 부팅을 시도하면 fsck가 자동으로 실행되는 것처럼 보입니다. 이해할 수 없는 이유로 여러 디렉터리의 모든 파일을 삭제한 다음 중요한 메타데이터 블록을 바로 0xFF로 덮어씁니다. 이 작업은 자동으로 수행됩니다. 이 "수정"에 대해 승인을 요청할 필요가 없습니다.

몇 가지 질문이 있습니다.

1. 파일 시스템 로그 손상으로 인해 fsck가 조정하려고 애쓰고 있기 때문일 수 있습니까? 그렇지 않다면 무엇이 원인일 수 있습니까?

2. 저널링 기능이 있는 Ext4가 실제로 이전 ext2 또는 ext3 파일 시스템보다 이 오류 모드를 통해 데이터 손실에 더 취약한 이유가 있습니까?

3. 이런 일이 다시는 발생하지 않도록 가능한 한 많이 보장하기 위해 다음 데이터 디스크 파일 시스템을 어떻게 구성합니까? 가능한 최신 데이터 디스크를 복원한 다음 체크섬이 활성화된 Ext4 파일 시스템을 설정할 계획입니다. 또한 로그의 체크섬을 활성화하는 옵션이 있다고 들었습니다. 이것이 바람직한가요? 저에게는 성능보다 안정성이 더 중요합니다. 하지만 대규모 RAID 어레이를 구축할 자금도 없습니다. 내 목적에 맞게 Ext4보다 더 나은 파일 시스템이 있습니까?

4. 부팅 시 또는 기타 방식으로 내 파일 시스템을 자동으로 "복구"하려는 fsck의 시도를 제한하기 위해 Ubuntu Mate에서 옵션을 설정할 수 있습니까? 저널링을 비활성화하는 것이 더 나을까요? fsck가 파일을 자동으로 삭제하는 것을 원하지 않습니다! 사실 저는 fsck를 제거하고 자체 수정 코드를 작성하는 것을 심각하게 고려하고 있지만 더 쉬운 방법이 있어야 합니다.

다른 사람에게도 이런 일이 발생했는지 알아보기 위해 온라인으로 검색했지만 다른 사례는 찾을 수 없었습니다. 이러한 일반적인 실패 모드가 6개월 동안 나에게 세 번 발생하면 다른 많은 사람들에게도 영향을 미칠 것이 확실합니다. 그러나 온라인에서 이 문제에 대한 다른 설명을 찾을 수 없습니다.