제가 이해한 바에 따르면 하드 드라이브와 SSD는 드라이브 내부에 몇 가지 기본적인 오류 수정 기능을 구현하며, 대부분의 RAID 구성(예: mdadm)은 이를 사용하여 드라이브가 오류를 수정할 수 없어 오프라인으로 전환해야 하는 시기를 결정합니다. 그러나 이는 저장된 오류 진단이 100% 정확한지에 따라 달라집니다. 이는 사실이 아니며 2개 드라이브 RAID-1 미러와 같은 일반적인 구성은 취약할 수 있습니다. 한 드라이브의 일부 비트가 자동으로 손상되고 드라이브가 읽기 오류를 보고하지 않는다고 가정해 보겠습니다. 따라서 btrfs 및 ZFS와 같은 파일 시스템은 결함이 있는 드라이브 펌웨어, 결함이 있는 SATA 케이블 등을 신뢰하지 않도록 자체 체크섬을 구현합니다.
마찬가지로 RAM에도 신뢰성 문제가 있을 수 있으므로 이 문제를 해결하기 위해 ECC RAM이 있습니다.
내 문제는 이것이다: 2디스크 구성(예: 메인라인 커널 드라이버 사용)에서 드라이브 펌웨어가 포착하지 못하는 자동 손상/비트 부패로부터 Linux 스왑 파일을 보호하는 표준 방법은 무엇입니까? 제 생각에는 btrfs가 제공하는 것과 같은 구성에서 종단 간 보호가 부족하면 ECC RAM이 제공하는 마음의 평화가 어느 정도 상쇄됩니다. 하지만 좋은 방법이 생각나지 않습니다.
- btrfs는 스왑 파일을 전혀 지원하지 않습니다. btrfs 파일에서 루프 장치를 설정하고 교체할 수 있습니다. 하지만 문제가 있습니다.
- 무작위 쓰기 성능이 좋지 않습니다.https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
- 쓰기 중 복사를 비활성화하라는 제안은 체크섬도 비활성화하여 이 연습의 전체 요점을 무효화합니다. 그들은 데이터 파일에 자체적인 내부 보호 기능이 있다고 가정합니다.
- Linux의 ZFS에서는 ZVOL을 스왑 영역으로 사용할 수 있습니다. 이것이 작동할 것이라고 생각합니다.http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap- 그러나 내가 읽은 바에 따르면 ZFS는 일반적으로 메모리를 많이 요구하므로 스왑 전용 응용 프로그램에서 작동하게 하려면 이 문제를 해결하려면 약간의 작업이 필요할 것 같습니다. 첫 번째 선택은 아닐 것 같아요. 신뢰할 수 있는 스왑을 얻기 위해 트리 외부 커널 모듈을 사용해야 하는 이유는 제 능력으로는 불가능합니다. 오늘날 대부분의 최신 Linux 배포판/커널을 사용하여 이를 달성할 수 있는 방법이 있어야 합니까?
- 실제로 Linux 커널 메일링 리스트에는 메모리 관리자 자체 내에서 체크섬을 활성화하기 위한 패치가 포함된 스레드가 있습니다. 이것이 바로 제가 이 질문에서 이에 대해 논의하는 이유입니다. http://thread.gmane.org/gmane.linux.kernel/989246- 불행하게도 제가 아는 한 패치는 종료되었으며 제가 알 수 없는 이유로 업스트림에 적용되지 않았습니다. 안타깝지만 좋은 기능인 것 같습니다. 반면에 RAID-1에 스왑을 적용하는 경우 - 손상이 체크섬 복구 능력을 넘어서는 경우 메모리 관리자가 패닉 또는 그 이상일 수 있는 다른 드라이브에서 읽기를 시도하기를 원할 것입니다. 메모리 관리자가 해야 할 일.
간단히 말해서:
- RAM에는 오류를 수정하기 위한 ECC가 있습니다.
- 영구 저장소의 파일에는 오류 수정을 위한 btrfs가 있습니다.
- 교환이 있나요? ? ? <---이게 내 문제야
답변1
우리는 교환에서 검색된 데이터의 무결성을 신뢰합니다.스토리지 하드웨어체크섬, CRC 등이 있습니다.
위 댓글 중 하나에서 다음과 같이 말씀하셨습니다.
예, 하지만 디스크 자체 외부의 비트 플립은 방지할 수 없습니다.
여기서 "It"은 디스크의 체크섬을 나타냅니다.
이는 사실이지만,SATA는 32비트 CRC를 사용합니다.명령 및 데이터에 사용됩니다. 따라서 디스크와 SATA 컨트롤러 사이의 데이터가 감지되지 않은 채 손상될 가능성은 40억분의 1입니다. 즉, 지속적인 오류 소스는 전송된 125MiB마다 오류를 일으킬 수 있지만, 우주선과 같은 희귀한 무작위 오류 소스는 극히 낮은 비율로 감지할 수 없는 오류를 일으킬 수 있습니다.
또한 소스에서 전송된 125MiB당 오류 1개에 가까운 비율로 감지되지 않은 오류가 발생하는 경우 성능이 저하된다는 점을 인식하세요.나쁜수가 많기 때문에감지됨재전송이 필요한 오류입니다. 모니터링 및 로깅을 통해 적시에 문제를 경고하여 감지되지 않은 손상을 방지할 수 있습니다.
저장 미디어의 체크섬과 관련하여 모든 SATA(및 그 이전의 PATA) 디스크는 일종의 섹터별 체크섬을 사용합니다. "엔터프라이즈" 하드 드라이브의 특징 중 하나는 보호되는 섹터가 더 크다는 것입니다.추가 데이터 무결성 기능, 감지되지 않은 오류가 발생할 가능성이 크게 줄어듭니다.
이러한 조치가 없으면 의미가 없습니다.예비 섹터 풀모든 하드 드라이브: 드라이브 자체는 불량 섹터를 감지할 수 없으므로 새 섹터를 교체할 수 없습니다.
다른 댓글에서는 다음과 같이 질문하셨습니다.
SATA가 그렇게 신뢰할 수 있다면 왜 ZFS, btrfs, ReFS 등과 같은 체크섬 파일 시스템이 있습니까?
일반적으로 우리는 장기 저장 데이터의 교환을 요구하지 않습니다. 스왑 저장 용량 한도는 시스템 전체에 적용됩니다.가동 시간, 시스템의 가상 메모리 시스템을 통과하는 대부분의 데이터는 수명이 짧은 프로세스에 속하기 때문에 스왑에 있는 대부분의 데이터는 오래 지속되지 않습니다.
게다가 코어와 코어 실행 빈도가 증가함에 따라 가동 시간은 일반적으로 수년에 걸쳐 감소했습니다.libc업데이트, 가상화, 클라우드 아키텍처 등
또한 스왑에 있는 대부분의 데이터는 기본 RAM 자체를 소모하지 않기 때문에 잘 관리되는 시스템에서는 본질적으로 사용되지 않습니다. 그러한 시스템에서 교환으로 끝나는 유일한 것은페이지이 프로그램은 거의 사용되지 않습니다. 이것은 당신이 생각하는 것보다 더 일반적입니다. 프로그램이 링크하는 대부분의 동적 라이브러리에는 프로그램에서 사용하지 않는 루틴이 포함되어 있습니다.동적 링커. 운영 체제는 라이브러리에 있는 프로그램 텍스트 중 일부를 사용하지 않는다는 사실을 발견하면 이를 교체하여 프로그램 코드와 데이터를 위한 공간을 확보합니다.예사용. 이렇게 교체된 메모리 페이지가 손상되면 누가 알겠습니까?
ZFS와 달리 우리는 데이터가 시스템의 현재 가동 시간 이후뿐만 아니라 스토리지 시스템을 구성하는 개별 스토리지 장치의 수명을 넘어 지속되도록 데이터를 지속적으로 저장하기를 원합니다. ZFS 해결과 같은 문제는 교환으로 해결된 문제보다 약 2배 더 긴 시간 규모를 갖습니다. 따라서 ZFS에 대한 손상 감지 요구 사항은 Linux 스왑 영역보다 훨씬 높습니다.
ZFS 등은 또 다른 주요 방식으로 스왑과 다릅니다. 스왑 파일 시스템을 함께 RAID하지 않습니다. 언제다중 스위칭 장치기계에 사용되며,JBODRAID-0 이상과 달리 구성표입니다. (예를 들어, macOS의체인 교환 파일 구성표, 리눅스swapon등) 스왑 장치는 독립적이고 RAID처럼 서로 종속되지 않으므로 많은 체크섬이 필요하지 않습니다. 스왑 장치를 교체할 때 교체 장치에서 실행되어야 하는 데이터에 대해 다른 상호 의존적인 스왑 장치를 찾을 필요가 없기 때문입니다. 장치 . ZFS 용어에서는 다른 저장 장치의 중복 복사본에서 스왑 장치를 다시 동기화하지 않습니다.
이 모든 것은 안정적인 스위칭 장치를 사용해야 함을 의미합니다. 한번은 실패한 ZFS 풀을 구하기 위해 20달러짜리 외부 USB HDD 인클로저를 사용한 적이 있는데, 인클로저 자체가 신뢰할 수 없고 프로세스에서 자체 오류가 발생한다는 사실을 발견했습니다. ZFS의 강력한 체크섬이 나를 구해주었습니다. 파일을 교환하면 저장 매체를 그렇게 거칠게 다룰 수 없습니다. 스왑 장치가 수명을 다하고 125MiB 전송마다 감지할 수 없는 오류가 주입되는 최악의 시나리오에 접근하는 경우 가능한 한 빨리 교체하면 됩니다.
이 질문에 대한 편집증의 전반적인 감각은 예를 들어 설명됩니다.비잔틴 장군 문제. 주의 깊게 읽고, 컴퓨터 과학 커뮤니티에 문제를 설명하는 학술 논문의 1982년 날짜를 고려하고, 2019년에 문제에 대한 새로운 생각이 있는지 결정하십시오. 그렇지 않다면 아마도 그럴 것이다.사용이 기술은 비잔틴 장군 문제를 이해하고 있는 컴퓨터 과학 졸업생 30명에 의해 설계되었습니다.
이것은 진부한 표현입니다. 컴퓨터 과학 저널에서 다루지 않은 아이디어, 반대, 해결책이 떠오르지 않을 수도 있습니다.
SATA는 확실히 완전히 신뢰할 수는 없지만 학계나 커널 개발 팀에 합류할 계획이 없다면 기존 기술에 실질적인 기여를 할 수 없습니다. 이미 알고 있듯이 이러한 문제는 이미 매우 잘 해결되었습니다. ZFS, btrfs, ReFS... 운영 체제 사용자로서 운영 체제 작성자가 이러한 문제를 해결하고 있다는 것을 신뢰해야 합니다. 비잔틴 장군에 대해 알아보세요.
이것은현재는 실용적이지 않음스왑 파일을 ZFS 또는 Btrfs에 넣습니다. 그러나 위의 내용으로 안심할 수 없다면 최소한 xfs 또는 ext4에 넣을 수 있습니다. 이는 전용 스왑 파티션을 사용하는 것보다 낫습니다.
답변2
DM-무결성
바라보다:문서/device-mapper/dm-integrity.txt
dm-integrity일반적으로 로그 모드에서 사용됩니다. 교환의 경우 로그를 남기지 않도록 설정할 수 있습니다. 이렇게 하면 성능 오버헤드를 크게 줄일 수 있습니다. 비정상적으로 종료된 후 오류가 발생하지 않도록 부팅할 때마다 스왑 무결성 파티션을 다시 포맷해야 하는지 잘 모르겠습니다.
내부에예비 발표dm-integrity, 저자는 "더 높은 수준의 데이터 무결성 보호"를 선호한다고 표현했습니다. 스와핑의 경우 체크섬을 RAM에 저장할 가능성이 열립니다. 그러나 이 옵션을 사용하려면 현재 스왑 코드를 크게 수정해야 하고 메모리 사용량도 늘어납니다. (현재 코드는 개별 페이지/섹터가 아닌 범위를 사용하여 스와핑을 효율적으로 추적합니다.)
DIF/DIX?
Oracle은 Linux 2.6.27에 DIX 지원을 추가합니다.(2008).
DIX를 사용하면 엔드투엔드 무결성이 제공됩니까?
공급업체에 문의하실 수 있습니다. 그들이 거짓말을 하고 있는지 어떻게 알 수 있는지 모르겠습니다.
데이터를 보호하려면 DIX가 필요합니다OS(운영 체제) 및하이드록시벤조산.
DIF 자체로 데이터 보호 강화HBA와 스토리지 장치 간 이동. (또한보십시오:일부 숫자를 사용하여 오류율의 차이를 보여줍니다.).
보호 필드의 체크섬이 표준화되어 있기 때문에 기술적으로 다음이 가능합니다.어느미사용 데이터를 보호하세요. HBA(또는 저장 장치)가 읽기 시 체크섬을 재생성하도록 하면 됩니다. 원래 DIX 프로젝트는 이 비전을 매우 명확하게 만들었습니다.
- DIF/DIX 예직교논리 블록 체크섬
- 우리는 여전히 당신을 사랑합니다, btrfs!
- 논리적 블록 체크섬 오류는 손상된 데이터를 감지하는 데 사용됩니다.
- 읽기 시 감지 발생
- ...어쩌면 몇 달 후에 원래 버퍼가 손실될 수도 있습니다.
- 원본 버퍼가 왜곡되면 중복된 복사본도 손상될 수 있습니다.
- DIF/DIX는 약입니다.부패를 적극적으로 예방하라
- 잘못된 데이터가 디스크에 저장되는 것을 사전에 방지하세요
- ...원래 버퍼가 메모리에서 제거되기 전에 문제를 찾아냅니다.
DIX에 대한 초기 게시물 중 하나에서는 드라이브가 DIF를 지원하지 않더라도 운영 체제와 HBA 간에 DIX를 사용할 수 있다고 언급했습니다.
DIX가 사용되는 현재 "기업" 환경에서는 노골적인 거짓말이 거의 눈에 띄지 않습니다. 또한 DIF는 기존 하드웨어를 기반으로 하며 520바이트 섹터를 사용하여 포맷할 수 있습니다. DIF를 사용하기 위한 프로토콜에서는 먼저 드라이브를 다시 포맷해야 합니다. sg_format명령 등을 참조하세요.
구현이 실제를 따르지 않을 가능성이 높습니다.엔드투엔드 원칙. 예를 들어, 공급업체가 CPU 주기를 절약하기 위해 DIX에 대해 더 약한 체크섬 옵션을 지원한 후 해당 옵션이 스택 아래로 더 강력한 체크섬으로 대체되었다고 언급합니다. 이는 유용하지만 완전한 종단 간 보호는 아닙니다.
또는 운영 체제에서 자체 체크섬을 생성하여 애플리케이션 마크 공간에 저장할 수 있습니다. 하지만현재 Linux(v4.20)에서는 이 기능을 지원하지 않습니다.. 2014년에 작성된 리뷰에서는 "실제로 애플리케이션 탭 공간의 사용을 허용하는 저장 장치가 거의 없기" 때문일 수 있다고 제안합니다. (이것이 저장 장치 자체를 가리키는지, HBA를 가리키는지, 아니면 둘 다를 가리키는지 확실하지 않습니다.)
Linux에서는 어떤 유형의 DIX 장치를 사용할 수 있습니까?
데이터와 무결성 메타데이터 버퍼의 분리와 체크섬 선택을 데이터 무결성 확장(DIX)이라고 합니다. 이러한 확장은 프로토콜 본문(T10, T13)의 범위를 벗어나기 때문에 Oracle과 그 파트너는 Storage Networking Industry Association 내에서 이를 표준화하려고 노력하고 있습니다.
Wikipedia에 따르면 DIF는 NVMe 1.2.1에서 표준화되었다고 합니다. SCSI HBA의 경우 참조할 표준이 없으면 이를 판단하기 어려울 것 같습니다. 지금으로서는 "Linux DIX" 지원에 대해 이야기하는 것이 가장 정확할 것입니다 :-). 사용 가능한 장치는 다음과 같습니다.
Red Hat Enterprise Linux 7.4는 하드웨어 공급업체가 이를 인증하고 특정 HBA 및 스토리지 어레이 구성을 완벽하게 지원하는 경우 SCSI T10 DIF/DIX [sic]를 완벽하게 지원합니다. DIF/DIX는 다른 구성에서는 지원되지 않으며, 부팅 장치에서의 사용도 지원되지 않으며, 가상화된 게스트에서도 지원되지 않습니다.
현재 이 지원을 제공하는 것으로 알려진 공급업체는 다음과 같습니다.
RHEL 7.5 릴리스 정보에 언급된 모든 하드웨어는 Fibre Channel입니다.
나는 이 시장을 이해하지 못한다. 앞으로는 DIX가 서버에서 더 광범위하게 사용될 것으로 보입니다. 소비자급 SATA 디스크에서 작동하는 이유를 모르겠습니다. 제가 아는 한 명령 형식에 대한 사실상의 표준조차 없습니다. NVMe에서 더 널리 사용할 수 있는지 확인하고 싶습니다.
답변3
교환이 있나요? ? ? <---이게 내 문제야
교환이 남아요보호되지 않음Linux에서(단, UPD 참조)
물론 Linux의 ZFS를 스왑 저장소로 사용할 수 있습니다.하지만 아직 자물쇠가 있어어떤 경우에는 옵션을 효과적으로 취소합니다.
Btrfs는 여전히 스왑 파일을 처리할 수 없습니다.. 그들은 성능이 좋지 않더라도 루프백을 사용할 수 있다고 언급했습니다. Linux 5에 마침내 그런 기능이 탑재될 것이라는 조짐(?)이 있습니다…
레거시 스위칭을 보호하기 위한 패치체크섬을 사용하면 그 자체로는 주류가 되지 않습니다.
요약하면: 아니요. Linux는 이 영역에서 아직 격차가 있습니다.
UPD.: 처럼 @소스 제다이 지적dm-integrity와 같은 도구가 있습니다. 버전 4.12 이후 Linux 커널은 모든 범용 블록 장치에 대한 체크섬을 제공하는 데 사용할 수 있는 장치 매퍼 대상을 얻었으며 스와핑에 사용되는 장치도 예외는 아닙니다. 이 도구는 주요 배포판에 널리 통합되지 않았으며 대부분의 배포판은 udev 하위 시스템을 지원하지 않지만 결국에는 변경되어야 합니다. MD(Linux 소프트웨어 RAID) 위에 배치되는 것과 같은 중복 공급자와 쌍을 이루는 경우 비트 부패를 감지할 수 있을 뿐만 아니라 I/O 요청을 정상 데이터로 다시 라우팅할 수 있습니다. dm-integrity가 문제가 있음을 나타내고 MD가 이를 표시해야 하기 때문입니다. 처리해.
답변4
나는 "표준적인" 방법이 없다고 생각하므로 다음은 내 개인적인 의견입니다.
잠재 사용자의 관점에서 btrfs의 진행 상황을 모니터링한 결과, 여전히 나에게는 다소 모호하다고 말해야 합니다. 일부 기능은 성숙하여 프로덕션에 사용할 준비가 되어 있는 반면, 일부 기능은 아직 성숙하지 않아 사용하기 위험해 보입니다.
개인적으로 어떤 기능을 사용할지, 어떤 기능을 사용하지 않을지 결정할 시간이 없기 때문에 해당 기능을 끄거나 켜는 방법을 알아내는 데 시간을 투자해야 합니다.
이에 비해 ZFS는 견고하고 성숙합니다(IMHO). 따라서 귀하의 질문에 답하기 위해 ZFS를 사용하겠습니다(그런데 메모리를 많이 소비하지 않습니다. 아래 참조).
그러나 btrfs는 이미 사용하고 있고(제 추측이 맞다면) 위의 설명 중 하나가 이를 스왑에 사용하는 방법을 보여주기 때문에 올바른 선택일 수 있습니다.
순전히 우연히 지난 며칠 동안 루트 파일 시스템과 스왑을 포함하여 몇 대의 Linux 서버를 ZFS에 설치했습니다. 이 작업을 수행하기 전에 저는 몇 가지 철저한 조사를 수행했는데 며칠이 걸렸습니다. 제가 배운 내용을 간략하게 요약하면 다음과 같습니다.
ZFS 메모리 소비
ZFS의 메모리 소비에 대한 일반적인 오해가 있습니다. ZFS는 일반적으로 다음과 같습니다아니요많은 메모리를 소비합니다. 실제로 2GB RAM이 있는 시스템에서 테라바이트의 저장 공간으로 실행될 수 있습니다. 사용하는 경우에만중복 제거(기본적으로 꺼져 있음) 많은 RAM이 필요합니다.
하드웨어 오류 감지/수정
SATA, PATA, RAID 또는 기타 오류 감지/수정 메커니즘이 데이터 무결성을 보장하기에 충분한지 여부는 웹의 다양한 곳에서 끝없는 토론과 열띤 논쟁을 불러일으키는 주제입니다. 이론적으로 하드웨어 저장 장치는 발생한 모든 오류를 보고하고 수정해야 하며 다양한 수준의 데이터 전송 하드웨어(칩셋, 메모리 등)도 동일한 작업을 수행해야 합니다.
글쎄, 그들은 모든 경우에 그렇게 하지 않거나 오류에 놀라울 정도로 잘 반응합니다. 일반적인 RAID5 구성을 예로 들어보겠습니다. 일반적으로 하나의 디스크에 문제가 있으면 이를 RAID에 보고하고 RAID는 다른 디스크에서 읽을 데이터를 구축하여 전달하지만 오류가 발생한 디스크에 다시 씁니다(디스크를 다시 매핑할 수 있음). 데이터를 쓰기 전 섹터), 동일한 디스크가 너무 많은 오류를 보고하는 경우 RAID는 해당 디스크를 오프라인으로 전환하고 관리자에게 알립니다(올바르게 구성된 경우).
지금까지는 괜찮았지만 어떤 경우에는 디스크에서 오류를 보고하지 않고 잘못된 데이터가 디스크에서 빠져나옵니다(다음 섹션 참조). 대부분의 RAID는 패리티 정보를 사용하여 이러한 상황을 감지할 수 있지만 반응은 어리석습니다. 오류를 보고하고 데이터 전송을 중지하는 대신,잘못된 데이터를 기반으로 패리티를 다시 계산합니다.그리고 해당 디스크에 새로운 패리티가 기록되어 잘못된 데이터가 영원히 올바른 것으로 표시됩니다.
이것이 합리적인 행동인가? 내가 아는 한 대부분의 하드웨어 RAID5 컨트롤러와 심지어 Linux의 md RAID도 이런 방식으로 작동합니다.
btrfs 오류 수정에 대해서는 잘 모르지만 특히 RAID에 btrfs를 사용하는 경우에는 설명서를 다시 주의 깊게 읽어야 합니다.
조용한 비트 부패
모든 열띤 논쟁과 (유사)과학적 토론에도 불구하고 현실은 대부분 이론과 다르며 이론은 이와 반대라고 말할 수도 있지만 자동 비트 부패는 확실히 발생합니다(자동 비트 부패는 일반적으로 하드웨어 저장소의 데이터가 손상되고 저장 장치가 손상되는 것을 의미합니다). 이 데이터를 읽는 동안 오류가 보고되지 않았지만 전송 경로의 어느 위치에서든 이 정의에 플립 비트를 추가하겠습니다.
이런 일이 일어나고 있다는 것은 내 개인적인 의견이 아닙니다. 적어도 Google, Amazon 및 CERN은 해당 주제를 다루는 자세한 백서를 발표했습니다. 이 논문은 일반인이 무료로 다운로드할 수 있습니다. 그들은 감지되지 않은 데이터 손상 문제에 직면했거나 문제가 발생하기 전에 이를 중지하는 방법을 알고 싶었기 때문에 수백만 개의 하드 드라이브와 수십만 개의 서버/저장 장치에 대해 체계적인 실험을 수행했습니다.
전반적으로 서버 팜의 데이터는 MTBF 통계나 다른 이론에서 예측하는 것보다 훨씬 더 높은 비율로 손상되었습니다. 그리고 훨씬 더 높다는 것은 규모의 순서를 의미합니다.
따라서 자동 비트 손상(즉, 전송 경로의 어느 지점에서도 감지되지 않는 데이터 손상)은 실제 문제입니다.
데이터 생활
교환된 데이터의 수명주기가 짧다는 Warren Young의 말은 옳습니다. 그러나 나는 다음과 같은 고려 사항을 추가하고 싶습니다.데이터(문서화 측면에서) 스왑으로 전환되지만 운영 체제나 기타 일부는 (아마도)소프트웨어 실행. MP3를 교환하면 비트를 뒤집으면서도 살아갈 수 있습니다. (극단적인 경우로 인해) 프로덕션 httpd 서버 소프트웨어의 일부가 교환된 상태에 있는 경우, 감지되지 않으면 이후에 손상된 코드가 실행될 수 있는 비트를 뒤집는 것을 절대 참을 수 없습니다.
결론
저에게 ZFS는 이러한 문제를 해결합니다. 더 정확하게는 문제를 디스크에서 메모리로 이동하여 문제가 발생할 가능성을 줄입니다.조용한비트는 몇 배로 감쇠됩니다. 또한 올바르게 구성되면(예: RAID가 아닌 미러링) 깨끗하고 합리적인 오류 수정을 제공하고 예상대로 작동하며 결국 이해하기 쉽습니다.
하지만 결코 완전히 안전할 수는 없다는 점에 유의하시기 바랍니다. 개인적으로 저는 디스크보다 ECC RAM을 더 신뢰하며 ZFS와 ZFS의 엔드투엔드 체크섬이 문제 발생 가능성을 몇 배나 줄일 수 있다고 믿습니다. 저 할 수 있어요안 돼요그러나 ECC RAM 없이 ZFS를 사용하는 것이 좋습니다.
면책 조항: 저는 ZFS 공급업체 또는 개발자와 아무런 관련이 없습니다. 이는 ZFS의 모든 변형(포크)에 해당됩니다. 며칠만에 팬이 되었어요...