ext4 파일 시스템은 안전한가요? [폐쇄]

나의 주요 관심사는 어쨌든 NTFS로 파티션된 디스크에서는 이러한 손상이 결코 발생하지 않는다는 것입니다.

아마 그런 일은 없었을 거야너, 하지만 이미 그런 일이 일어났습니다. 그러한 일이 결코 일어나지 않는다고 주장할 수 있는 유일한 파일 시스템은 그러한 조건에 노출된 적이 없는 시스템입니다. BTRFS와 ZFS가 모두 이러한 문제를 견디도록 설계되었더라도 그러한 문제가 존재할 수 있습니다.

그러나 실제 질문의 경우:

ext4는 일반적으로 안전합니까? 저 또는 다른 사람이 etx4로 포맷된 디스크/디스크에 대한 정보 손실을 경험한 적이 있습니까?

"안전하다"는 것이 무엇을 의미하는지에 따라 다릅니다. 저는 개인적으로 포맷한 디스크의 데이터를 잃어버렸습니다 ext4. 하지만 이런 일이 발생할 때마다 하드웨어 오류로 인해 발생했으며 더 중요한 것은 결국 거의 모든 다른 파일 시스템에서도 이런 일이 발생한다는 것입니다. 그럼에도 불구하고 나는 사용자 오류나 하드웨어 문제(예기치 않은 정전 포함)가 없으면 잘 작동하기 때문에 여전히 여러 가지 용도로 정기적으로 사용합니다. 그래서,나대부분의 사람들의 정의에 따르면 "안전하다"고 생각하지만 그럴 수도 있고 아닐 수도 있습니다.

Linux 세계에서 예상치 못한 정전이나 예상치 못한 제거에도 견딜 수 있는 ext4보다 더 안전한 대안은 무엇일까요?

아니요, 다른 제한사항이나 문제를 처리하려는 경우가 아니면 가능합니다. 특히:

• XFS는 예상치 못한 정전에 대해 더 탄력적이며 ext4처럼 재부팅 시 오랜 확인이 필요하지 않습니다. 그러나 소규모 사용에는 의심스러울 정도로 많은 실질적인 제한 사항이 있습니다(파일 시스템을 축소할 수 없고 성능이 좋지 않음). 새 볼륨의 ext4만큼 좋지만 데이터 로깅은 없습니다.
• NILFS2는 정전으로 인해 종료되는 것이 거의 불가능하지만 30초 정도의 변경 사항이 손실될 수 있고 설치 시 사용자 공간 구성 요소가 필요하며 일반적으로 대부분의 Linux 파일 시스템에서 표준으로 간주되는 일부 기능이 부족합니다.
• BTRFS는 하드웨어 오류에 대한 면역성을 제공하고 상당히 안정적이며 오류가 발생한 디스크의 온라인 교체에 대한 우수한 지원을 제공하지만 예상치 못한 정전으로 인해 최신 변경 사항 중 일부가 손실될 수 있으므로 더 많은 작업을 수행해야 합니다. 대부분의 다른 파일 시스템보다 볼륨을 건강하게 유지하기 위해 수행됩니다.
• ZFS는 문제(관리 문제 제외) 없이 BTRFS의 모든 이점을 제공하지만 타사 커널 모듈을 구축해야 하며 엔터프라이즈급 하드웨어에서 실행하지 않으면 업스트림 지원을 받을 수 없습니다. .

그러나 ext4를 더욱 안전하게 만들기 위해 수행할 수 있는 몇 가지 작업이 있습니다.

• 오류가 발생하면 동작을 변경합니다. 기본적으로 파일 시스템 메타데이터에 오류가 발생하면 ext4는 해당 볼륨을 확인이 필요한 것으로 표시한 다음 아무 일도 일어나지 않은 것처럼 작동합니다. 이것은오직Linux의 파일 시스템이 이 작업을 수행하면 다른 모든 항목은 볼륨을 읽기 전용으로 다시 마운트하여 파일 시스템에 대한 쓰기가 상황을 악화시키는 것을 방지합니다. errors=remount-ro마운트 옵션을 추가하거나 파일 시스템이 포함된 블록 장치에서 실행하여 tune2fs -e remount-roext4에서 이 동작을 얻을 수 있습니다 .
• 당신이 있는지 확인아니요로그 쓰기 저장 모드를 사용합니다. 볼륨의 마운트 옵션을 다시 확인하고 목록에 없는지 확인하면 journal=writeback이를 확인할 수 있습니다. 로그 쓰기 저장 모드는 ext4 파일 시스템의 특정 워크로드에 대한 성능을 크게 향상시킬 수 있지만 예기치 않은 정전이 발생할 경우 데이터 손실 가능성이 높아집니다.
• 당신이되고 싶다면진짜데이터 보안 편집증의 경우 로그 데이터 모드를 활성화할 수 있습니다. 일반적으로 ext4 파일 시스템의 로그는 메타데이터 변경 사항(이름 변경, 파일 삭제 또는 생성, 타임스탬프 업데이트 등)만 추적합니다. 로그 데이터 모드에서는모두변경사항은 로그를 통해 이루어집니다. 이렇게 하면 작업 속도가 크게 느려지지만 파일 시스템이 내부적으로 일관성을 유지한다는 기능이 100% 보장됩니다. journal=data설치 옵션을 전달하여 이 기능을 활성화 할 수 있습니다 .
• auto_da_alloc설치 옵션을 추가할 수 있습니다 . 기본적으로 이는 fsync()애플리케이션이 호출되어야 할 때 호출되지 않는 상황을 감지하고 문제를 올바르게 처리합니다. 속도가 약간 느려지고 대부분의 응용 프로그램에는 필요하지 않으므로 기본값은 아닙니다.
• 최신 커널에서는 로그 체크섬을 활성화할 수 있습니다. 이렇게 하면 실제로 데이터가 "저장"되지는 않지만 문제가 발생할 경우 가짜 데이터를 얻지 못하게 하는 데 도움이 됩니다. 이는 journal_checksum설치 옵션을 추가하여 활성화할 수 있습니다.
• 충분히 새로운 커널과 e2fsprogs 버전이 있는 경우 메타데이터 체크섬을 활성화할 수 있습니다. 로그 체크섬과 마찬가지로 데이터가 저장되지는 ​​않지만 오류가 발생할 경우 가짜 데이터가 표시되는 것을 방지하는 데 도움이 됩니다. 파일 시스템이 생성될 때 -O metadata_checksum,metadata_checksum_seed전달 되어야 합니다 mkfs.ext4. 이렇게 하면 로그가 메타데이터 체크섬에 포함되는 항목의 일부이므로 로그 체크섬을 동시에 활성화할 필요가 없습니다.