BTRFS 데이터 무결성(CRC32c) 및 HDD 데이터 무결성(섹터 ECC)

디스크는 조용히 데이터를 손상시킬 수 있습니다. 바라보다http://storagemojo.com/2007/09/19/cerns-data-corruption-research/이는 이 연구의 한 예일 뿐입니다.

나는 디스크에 종종 보고되지 않은 오류가 있고 이를 FUD의 원인으로 간주한다는 주장을 받아들이지 않습니다. 예, 오류 감지 코드에 충분한 무작위 데이터를 던지면 실제로는 그렇지 않은데 데이터가 정확하다고 보고하는 경우가 있습니다. 하지만 문제는 드라이브가 임의의 데이터를 읽으려고 시도하지 않는다는 것입니다. 이는 올바르게 기록되고 다시 읽혀진 대부분의 데이터를 읽는 것입니다. 그런 다음 이는 많은 잘못된 비트를 수정할 수 있는 오류 수정 코드를 통해 전달됩니다. 보고되지 않은 오류를 얻으려면 평소보다 훨씬 더 많은 수의 원시 오류를 가져와 ECC를 압도해야 하며 그런 다음 이를 정렬해야 합니다.바로ECC의 출력이 스스로 정렬되도록바로그것은 EDC가 그것이 좋다고 생각하도록 속였습니다. 확률은 다음과 같습니다많은더 높을수록 최소한 EDC는 오류를 인지하고 수정할 수 없는 오류로 보고합니다. 얼마나 자주저것발생하다? 드라이브가 곧 고장나거나 쓰기 도중에 갑자기 전원이 꺼지는 경우를 제외하고는 기본적으로 절대로 사용하지 마십시오. 따라서 수정 불가능한 오류가 거의 발생하지 않고 보고되지 않은 오류가 발생할 가능성이 백만 배 낮다면 이는 무엇을 의미할까요?

반면에 데이터의 중복 복사본을 저장하는 경우 극히 드물지만 한 복사본이 자동으로 손상되는 경우 어떤 복사본이 올바른지 알 수 있는 방법이 있으면 좋을 것입니다. 또한 crc는 동일한 데이터의 중복 복사본이 포함된 블록을 감지하는 데 유용하므로 btrfs의 또 다른 설계 기능인 중복 제거가 가능합니다.

예, 처음에는 장치가 오류를 보고하거나 올바른 데이터를 저장하는 것을 신뢰하지 않습니다. 이것이 정말로 필요한지 여부는 완전히 다른 질문입니다. 일반적으로 이는 누구도 걱정하지 않으며 모든 것이 잘 작동합니다.

디스크가 오류를 보고하지 않으면 파일 시스템이 이러한 오류 보고에 의존할 뿐만 아니라 다른 구성 요소(예: RAID 컨트롤러 등)도 전체 데이터를 저장하므로 큰 문제가 발생하게 됩니다. 위험에 처한 사람은 소수가 아닙니다.

파일 시스템이 체크섬을 수행하는지 여부에 관계없이 항상 스토리지에서 SMART 자체 테스트와 같은 자체 테스트를 실행해야 하며, RAID의 경우 패리티 데이터 불일치를 확인해야 합니다( /sys/block/mdX/md/mismatch_cntcheck sync_action=0 실행 후).

btrfs차세대 파일 시스템입니다. 이는 과거에 이들 사이에서 처리되었던 계층 모델과 동일한 목적을 많이 포함합니다. btrfs또한 매우 광범위한 스택 - FAQ에서는 분할되지 않은 디스크 *[들]*에 쓰기와 모든 파티셔닝, 할당량, 압축, 이미징, 스트라이핑, 기록 중 복사, 중복 제거 및 가능하면 10개를 권장합니다. 제가 별도로 언급하지 않은 또 다른 기능이 있습니다. 파일 시스템의 품질 때문입니다. 이 모든 일과 그 이상을 할 수 있습니다.

btrfs디스크 어레이는 동적이므로 라이브 시스템에서 문제 없이 추가하고 제거할 수 있습니다. 이는 btrfs메모리 블록 그룹이 필요할 때만 청크되어 현재 어레이의 특정 장치에 있을 수 있기 때문에 작동합니다 . FAQ에는 이에 대해 언급된 내용이 있습니다. 특히 여유 공간 추정치의 신뢰성이 떨어지는 경우에 그렇습니다.

예를 들어, 하나의 하위 볼륨이 단일이고 다른 하나가 RAID-1인 경우 첫 번째 하위 볼륨은 기록된 모든 데이터 바이트에 대해 1바이트 비율로 원시 스토리지 공간을 사용합니다. 두 번째 하위 볼륨은 기록된 모든 데이터 바이트에 대해 2바이트의 원시 데이터를 차지합니다. 따라서 사용 가능한 원시 공간이 30GiB인 경우 첫 번째 하위 볼륨에 30GiB의 데이터를 저장하거나 두 번째 하위 볼륨에 15GiB의 데이터를 저장할 수 있으며 사용자가 해당 데이터에 쓸 때까지 어느 것을 알 수 없습니다.

따라서 일반적으로 btrfs 파일 시스템의 여유 공간 크기를 정확하게 추정하는 것은 불가능합니다.응 안 좋아. 사용자가 얼마나 많은 공간이 남아 있는지 쉽게 알 수 있는 정말 좋은 아이디어가 있다면 알려주시기 바랍니다. 또한 btrfs 개발 분야의 최고 전문가들이 이 문제에 대해 적어도 몇 년 동안 생각해 왔다는 점에도 유의하세요. 아직까지 쉬운 해결책은 찾지 못했습니다.

btrfs관련 섹션을 읽으면 보다 구체적인 예를 얻을 수 있지만 장치 수는 가변적일 수 있고 지속성은 일시적이며 차단 및 스트라이핑은 개별적으로 또는 함께 수행될 수 있다는 것이 매우 분명해졌습니다 . 좋습니다. 계속됩니다. FAQ의 또 다른 인용문:

장치 관리는 복잡한 주제이며 최선의 접근 방식에 대해서는 다양한 의견이 있습니다. 내부적으로 Btrfs 코드는 장치 관리를 처리하는 구성 요소를 분리하고 해당 구성 요소에 대한 자체 계층을 유지 관리합니다. 파일 시스템 메타데이터의 대부분은 여러 장치와 관련된 것으로 알려져 있지 않습니다.

RAID에 대해 다음과 같이 말합니다.

btrfs는 RAID-0, RAID-1 및 RAID-10을 지원합니다. Linux 3.9부터 btrfs는 RAID-5 및 RAID-6도 지원하지만 코드는 아직 실험적입니다.

btrfs는 먼저 모든 장치를 스토리지 풀로 결합한 다음 파일 데이터를 생성하면서 블록을 복사합니다. RAID-1은 현재 "다른 장치에 있는 모든 데이터의 복사본 2개"로 정의됩니다. 이는 n 장치의 n 복사본을 만드는 MD-RAID 및 dmraid와 다릅니다. 3개의 1TB 장치에 대한 btrfs RAID-1에서는 1.5TB의 사용 가능한 데이터를 얻습니다. 각 블록은 2개의 장치에만 복사되므로 특정 블록을 쓰려면 정확히 2개의 장치에만 쓰기가 필요합니다. 읽기는 하나만 시작하면 됩니다.

데이터 복구:

btrfs-raid 5/6의 장점은 MD-RAID와 달리 btrfs는 어떤 블록이 데이터/메타데이터에 의해 실제로 사용되는지 알고 재구축/복원 상황에서 해당 정보를 사용하여 다시 추가되거나 재추가된 블록에서만 동기화/재구축할 수 있다는 것입니다. 실제로 사용되는 장치 블록을 교체하고 처음부터 완전히 사용되지 않거나 비어 있는 블록을 건너뜁니다.

MD-RAID는 파일 시스템에 구애받지 않는 레이어가 되려고 하고 그 위 레이어의 어떤 블록이 실제로 사용되거나 비어 있는지 모르거나 신경 쓰지 않기 때문에 이를 수행할 수 없습니다. 추적을 시도하면 계층화 위반이 되며, 코드를 심각하게 복잡하게 하거나 지원/이해/정확하게 추적할 수 있는 파일 시스템이나 다른 계층으로만 사용을 제한하게 됩니다.

물론 btrfs처음부터 설계되었습니다 .초월하다층. 이를 위해서는 현재 병합된 모든 장치의 체크섬을 포함하고 재구축이 가능하며 어느 정도 중복되는 트리를 유지해야 합니다. btrfs여러 면에서 이는 파일 데이터베이스이자 파일 시스템입니다. 대부분의 경우 ecc의 존재를 고려하지 않기 때문에 ecc의 기본 장치에 의존하지 않습니다.예기본 장비. 아마도 디스크 칡이라고 생각하시면 될 것 같습니다.

btrfs그럼에도 불구하고 기본 하드웨어에 대해 전혀 생각할 필요 없이 많은 흥미로운 작업을 수행 할 수 있는 것은 지속적인 체크섬 및 메타데이터 관리입니다 .