자동 디스크 오류 및 Linux 스왑의 안정성

내 이해는 하드 드라이브와 SSD가 드라이브 내부에 몇 가지 기본 오류 수정을 구현한다는 것입니다. mdadm과 같은 대부분의 RAID 구성은 드라이브가 오류를 수정하지 못하여 오프라인 상태로 만들어야하는 시점을 결정하기 위해 이것에 의존합니다. 그러나 이는 오류 진단에서 스토리지가 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
  • 기록 중 복사를 비활성화하라는 제안도 체크섬을 비활성화하므로이 연습의 요점을 모두 잃게됩니다. 데이터 파일에는 자체 내부 보호 기능이 있다고 가정합니다.
• : 리눅스에 ZFS는 일할 수있는 것 같아요 스왑으로 ZVOL를 사용하여 허용 http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap 그러나, 내 독서에서, ZFS는 일반적으로 메모리에 요구하고, 점점 그것은 스왑에서 작업 - 응용 프로그램 만 알아내는 작업처럼 들립니다. 나는 이것이 나의 첫번째 선택이 아니라고 생각한다. 안정적인 스왑을 위해 트리 외부 커널 모듈을 사용해야하는 이유는 무엇입니까?
• 나는이 문제에 대해 논의 정확히 이유로 메모리 관리자 자체 내에서 체크섬, 활성화 패치로 리눅스 커널 메일 링리스트에 스레드 실제로 있었다 : http://thread.gmane.org/gmane.linux.kernel/989246은 - 불행히도, 내가 알 수있는 한, 패치는 죽었고 나에게 알려지지 않은 이유로 업스트림으로 만들지 않았습니다. 너무 나쁘다, 그것은 좋은 기능처럼 들렸다. 반면에 RAID-1에 스왑을 설정하면 손상이 체크섬으로 복구 할 수없는 경우 메모리 관리자가 당황하기 전에 다른 드라이브에서 다른 드라이브를 읽으려고합니다. 아마도 메모리 관리자가해야 할 일의 범위를 벗어난 것입니다.

요약하자면:

• RAM에 ECC가 오류를 수정했습니다.
• 영구 저장소의 파일에는 오류를 수정하기위한 btrfs가 있습니다
• 스왑은 ?? <--- 이것은 내 질문이다

스토리지 하드웨어 에는 체크섬, CRC 등이 있기 때문에 스왑에서 검색된 데이터의 무결성을 신뢰합니다 .

위의 의견 중 하나에서 다음과 같이 말합니다.

사실이지만 디스크 외부의 비트 플립으로부터 보호되지는 않습니다.

"It"는 디스크의 체크섬을 의미합니다.

사실이지만 SATA는 명령 및 데이터에 32 비트 CRC 를 사용합니다. 따라서 디스크와 SATA 컨트롤러간에 40 억의 1 확률로 데이터를 감지 할 수 없습니다. 즉, 연속 오류 소스는 125MiB가 전송 될 때마다 오류가 발생할 수 있지만 우주 광선과 같은 드문 무작위 오류 소스는 거의 작은 비율로 감지 할 수없는 오류를 일으킬 수 있습니다.

전송 된 125MiB 당 1 개에 가까운 속도로 감지되지 않은 오류를 발생시키는 소스가있는 경우 성능이 끔찍합니다. 때문에 높은 수의 검출 재 전송을 요구하는 오류. 모니터링 및 로깅은 감지되지 않은 손상을 피하기 위해 시간 내에 문제를 경고합니다.

저장 매체의 체크섬과 관련하여 모든 SATA (및 그 이전의 PATA) 디스크는 어떤 종류의 섹터 별 체크섬을 사용합니다. "기업"하드 디스크의 특징 중 하나는 추가 데이터 무결성 기능으로 이며, 감지되지 않은 오류의 가능성을 크게 줄입니다.

그러한 조치가 없다면 모든 하드 드라이브 예비 섹터 풀 을 . 드라이브 자체는 불량 섹터를 감지 할 수 없으므로 새로운 섹터를 교체 할 수 없습니다.

다른 의견에서는 다음과 같이 묻습니다.

SATA가 그렇게 믿을만하다면 왜 ZFS, btrfs, ReFS와 같은 체크섬 파일 시스템이 있습니까?

일반적으로 스왑은 데이터를 장기적으로 저장할 것을 요구하지 않습니다. 스왑 스토리지의 한계는 시스템의 가동 시간 이며 스왑의 대부분의 데이터는 시스템의 가상 메모리 시스템을 통과하는 대부분의 데이터가 훨씬 짧은 프로세스에 속하기 때문에 거의 오래 지속되지 않습니다.

게다가 가동 시간은 일반적으로 커널의 빈도와 libc 업데이트 , 가상화, 클라우드 아키텍처 등으로 .

또한 스왑의 대부분의 데이터는 기본적으로 잘 관리되는 시스템에서 기본 RAM으로 실행되지 않는 시스템으로 사용되지 않습니다. 이러한 시스템에서 스왑으로 끝나는 유일한 것은 프로그램이 자주 사용하지 않는 페이지 입니다. 이것은 당신이 생각하는 것보다 더 일반적입니다. 프로그램이 링크하지 않는 대부분의 동적 라이브러리에는 프로그램에서 사용하지 않는 루틴이 있지만 동적 링커에서 RAM으로로드해야합니다 . OS가 라이브러리에서 모든 프로그램 텍스트를 사용하지 않는 것을 발견하면, 텍스트를 교체하여 프로그램 이 사용 하는 코드와 데이터를위한 공간을 만듭니다 . 스왑 아웃 된 메모리 페이지가 손상되면 누가 알겠습니까?

이것은 데이터가 지속적이고 지속적으로 저장 될 것으로 예상되는 ZFS와 유사하므로 시스템의 현재 가동 시간뿐만 아니라 스토리지 시스템을 구성하는 개별 스토리지 장치의 수명을 넘어 지속됩니다. ZFS 등은 스왑으로 해결 된 문제보다 약 2 배 더 긴 시간 규모의 문제를 해결하고 있습니다. 따라서 Linux 스왑보다 ZFS의 손상 감지 요구 사항이 훨씬 높습니다.

ZFS와 이와 같은 점은 여기서 또 다른 핵심 방식으로 스왑과 다릅니다. 파일 시스템을 함께 RAID 스왑하지 않습니다. 때 여러 스왑 장치가 단일 시스템에서 사용중인, 그것은이다 JBOD를 하지 RAID-0 이상 같은 계획. (예 : macOS의 체인 스왑 파일 체계 , Linuxswapon 등) 스왑 장치는 RAID와 상호 의존하지 않고 독립적이므로 스왑 장치를 교체 할 때 다른 상호 종속 스왑 장치를 찾아 볼 필요가 없으므로 광범위한 체크섬이 필요하지 않습니다. 교체 기기에 있어야 할 데이터. ZFS 용어로, 우리는 다른 저장 장치의 중복 복사본에서 장치를 교체하지 않습니다.

이 모든 것이 안정적인 스왑 장치를 사용해야한다는 것을 의미합니다. 나는 한 번에 20 달러의 외부 USB HDD 인클로저를 사용하여 병든 ZFS 풀을 구출하고 인클로저 자체가 신뢰할 수 없다는 것을 발견하고 자체 오류를 프로세스에 도입했습니다. ZFS의 강력한 체크섬은 나를 구해 주었다. 스왑 파일을 사용하여 스토리지 미디어를 무심코 처리 할 수는 없습니다. 스왑 장치가 죽어 125 MiB가 전송 될 때마다 감지 할 수없는 오류를 발생시킬 수있는 최악의 상황에 도달하면 간단히 교체해야합니다.

이 질문에 대한 편집증의 전반적인 감각은 비잔틴 장군 문제 의 사례와 관련 이 있습니다 . 컴퓨터 과학 세계에 대한 문제를 설명하는 학술지에 1982 년 날짜를 숙고 한 다음 2019 년에이 문제에 추가 할 새로운 생각이 있는지 여부를 결정하십시오. 그렇지 않다면 비잔틴 장군 문제에 대해 모두 알고있는 30여 명의 CS 졸업생이 설계 한 기술을 사용 하게 될 것 입니다.

이것은 획기적인 땅입니다. 컴퓨터 과학 저널에서 아직 논의되지 않은 아이디어, 이의 제기 또는 솔루션을 생각해 낼 수 없을 것입니다.

SATA는 확실히 신뢰할 만하지는 않지만 학계 나 커널 개발 팀에 합류하지 않는 한 여기서 최신 기술에 실질적으로 추가 할 수는 없습니다. ZFS, btrfs, ReFS ... OS 사용자는 OS 제작자가 이러한 문제를 해결하고 있다는 사실 만 알고 있으면됩니다. 비잔틴 장군에 대해.

이다 현재 실용적이지 ZFS 또는 BTRFS의 상단에 스왑 파일을 넣어하지만, 위 조건에 해당 안심하지 않는 경우, 당신은 적어도 XFS 또는 ext4가 꼭대기에 넣을 수 있습니다. 전용 스왑 파티션을 사용하는 것보다 낫습니다.

dm 무결성

참조 : Documentation / device-mapper / dm-integrity.txt

dm-integrity일반적으로 저널링 모드에서 사용됩니다. 스왑의 경우 저널링없이 할 수 있습니다. 이로 인해 성능 오버 헤드가 크게 낮아질 수 있습니다. 부정한 종료 후 오류가 발생하지 않도록 각 부팅에서 스왑 오버 무결성 파티션을 다시 포맷해야하는지 확실하지 않습니다.

의 초기 발표dm-integrity 에서 저자는 대신 "상위 수준의 데이터 무결성 보호"에 대한 선호를 언급합니다. 스왑의 경우 체크섬을 RAM에 저장할 수 있습니다. 그러나이 옵션을 사용하면 현재 스왑 코드를 간단하게 수정하고 메모리 사용량을 늘릴 수 있습니다. (현재 코드 트랙은 개별 페이지 / 섹터가 아닌 익스텐트를 사용하여 스왑을 효율적으로 교환합니다).

DIF / DIX?

Linux 2.6.27에서 Oracle에 의해 DIX 지원이 추가되었습니다. (2008) .

DIX를 사용하면 종단 간 무결성이 제공됩니까?

공급 업체에 문의 할 수 있습니다. 그들이 거짓말하는지 어떻게 알 수 있는지 모르겠습니다.

OS (운영 체제)와 HBA 간에 비행중인 데이터를 보호하려면 DIX가 필요합니다 .

DIF 자체 는 HBA와 저장 장치 사이에서 비행 중인 데이터 에 대한 보호 기능을 향상시킵니다 . (또한 오류율 차이에 대한 수치가 포함 된 프리젠 테이션 참조 ).

가드 필드에서 검사가 표준화되어 정확하게 때문에, 그것을 제공하지 않고 DIX 명령을 구현하는 기술적 수 있는 휴식의 데이터를 보호. HBA (또는 저장 장치)가 읽기 시간에 체크섬을 재생성하도록하십시오. 이 전망은 원래 DIX 프로젝트에 의해 상당히 명확 해졌습니다.

• DIF / DIX는 논리 블록 체크섬 과 직교
  • 우리는 여전히 당신을 사랑합니다, btrfs!
  • 논리 블록 체크섬 오류는 손상된 데이터 감지에 사용됩니다.
  • 읽기 시간에 감지
  • ... 몇 달 후에 원래 버퍼가 손실 될 수 있습니다.
  • 원본 버퍼가 깨졌을 경우 중복 사본도 나빠질 수 있습니다
• DIF / DIX는 손상을 사전에 예방합니다
  • 잘못된 데이터가 디스크에 처음 저장되는 것을 방지
  • ... 그리고 원래 버퍼가 메모리에서 삭제되기 전에 문제에 대해 알아 내기

- oss.oracle.com에서 lpc08 - 데이터 integrity.pdf

DIX에 대한 초기 게시물 중 하나는 드라이브가 DIF를 지원하지 않는 경우에도 OS와 HBA간에 DIX를 사용할 수 있다고 언급합니다.

DIX가 현재 사용되고있는 "엔터프라이즈"환경에서는 완전한 멘 다시 티가 거의 없을 것입니다. 사람들은 그것을 알아 차릴 것입니다. 또한 DIF는 520 바이트 섹터로 포맷 할 수있는 기존 하드웨어를 기반으로했습니다. DIF 사용 프로토콜에 따르면 드라이브를 먼저 다시 포맷해야합니다 (예 : sg_format명령 참조) .

실제 엔드 투 엔드 원칙을 따르지 않는 구현이 더 가능성이 높습니다 . 한 가지 예를 들면, DIX가 CPU주기를 절약하기 위해 약한 체크섬 옵션을 지원하는 공급 업체를 언급 한 다음 스택에서 더 강한 체크섬으로 대체합니다. 이 기능은 유용하지만 완벽한 엔드 투 엔드 보호 기능은 아닙니다.

또는 OS가 자체 체크섬을 생성하여이를 애플리케이션 태그 공간에 저장할 수 있습니다. 그러나 현재 Linux (v4.20)에서는이를 지원하지 않습니다 . 2014 년에 작성된이 의견은 이것이 "어플리케이션 태그 공간 사용을 실제로 허용하는 저장 장치가 거의 없기 때문"일 수 있음을 시사합니다. (이것이 저장 장치 자체, HBA 또는 둘 다를 나타내는 지 확실하지 않습니다).

Linux에서 작동하는 DIX 장치에는 어떤 것이 있습니까?

데이터와 무결성 메타 데이터 버퍼의 분리와 체크섬에서의 선택을 데이터 무결성 확장 [DIX]이라고합니다. 이러한 확장이 프로토콜 본문 (T10, T13)의 범위를 벗어나므로 Oracle과 파트너는 스토리지 네트워킹 산업 협회 내에서이를 표준화하려고합니다.

- v4.20 / 문서 / 차단 / 데이터 integrity.txt

Wikipedia에 따르면 DIF는 NVMe 1.2.1에서 표준화되어 있습니다. SCSI HBA의 경우, 표준이 없으면이를 고정시키기가 약간 어려워 보입니다. 현재 "Linux DIX"지원에 대해 이야기하는 것이 가장 정확할 것입니다 :-). 사용 가능한 장치가 있습니다 :

SCSI T10 DIF / DIX [sic]는 하드웨어 공급 업체가 자격을 갖추고 특정 HBA 및 스토리지 배열 구성을 완벽하게 지원하는 경우 Red Hat Enterprise Linux 7.4에서 완벽하게 지원됩니다. DIF / DIX는 다른 구성에서 지원되지 않으며 부팅 장치에서 사용하도록 지원되지 않으며 가상화 된 게스트에서는 지원되지 않습니다.

현재 다음 공급 업체가이 지원을 제공하는 것으로 알려져 있습니다 ...

- RHEL 7.5 릴리즈 노트, 제 16 장 저장

RHEL 7.5 릴리스 정보에 언급 된 모든 하드웨어는 파이버 채널입니다.

나는이 시장을 모른다. DIX는 향후 서버에서 더 널리 사용될 수있을 것 같습니다. 명령 형식에 대한 사실상의 표준조차 없다는 것을 아는 한, 소비자 SATA 디스크에 사용할 수있는 이유를 모르겠습니다. NVMe에서 더 널리 사용할 수 있는지 확인하고 싶습니다.

스왑은 ?? <--- 이것은 내 질문이다

스왑은 여전히 Linux에서 보호되지 않습니다 (그러나 UPD 참조).

물론 스왑 스토리지가 가능한 Linux에는 ZFS가 있지만 일부 상황에서는 여전히 잠금 상태가되어 해당 옵션을 효과적으로 취소합니다.

Btrfs는 여전히 스왑 파일을 처리 할 수 ​​없습니다 . 성능이 좋지 않은 것으로 알려져 있지만 루프백을 사용할 수 있다고 언급합니다. Linux 5가 마침내 그것을 가질 수 있는지 확실하지 않은 징후가 있습니다 (?)…

체크섬으로 기존 스왑 자체 를 보호하는 패치 는 메인 스트림으로 만들지 못했습니다.

따라서 전체적으로 : 아닙니다. 리눅스는 여전히 틈이 있습니다.

UPD. : @ sourcejedi가 지적했듯이 dm-integrity와 같은 도구가 있습니다. 버전 4.12 이후의 Linux 커널은 일반적인 블록 장치 및 스왑을위한 체크섬을 제공하는 데 사용할 수있는 device-mapper의 대상을 얻었습니다. 툴링은 주요 배포판에 광범위하게 통합되어 있지 않으며 대부분 udev 하위 시스템에서 지원하지 않지만 결국 변경되어야합니다. 이중화 공급자와 쌍을 이루는 경우, MD (일명 Linux Software RAID) 위에 올려 놓으면 비트 썩음을 감지 할 수있을뿐만 아니라 dm-integrity가 문제와 MD가 처리해야합니다.

나는 "정식적인"방법이 없다고 생각하므로 다음은 제 개인적인 견해입니다.

잠재적 인 사용자 관점에서 btrfs의 진행 상황을 모니터링 한 후에도 여전히 btrfs가 여전히 모호하다고 말합니다. 성숙하고 생산에 사용할 준비가 된 기능이 있으며 사용하기에 미숙하고 위험한 것처럼 보이는 기능이 있습니다.

개인적으로, 어떤 기능을 사용할지, 어떤 기능을 사용할지 결정할 시간이 없습니다.

반대로 ZFS는 견고하고 성숙합니다 (IMHO). 따라서 귀하의 질문에 대답하기 위해 ZFS를 사용합니다 (그런데 많은 메모리를 소비하지 않습니다-아래 참조).

그러나 btrfs는 이미 사용하고 있기 때문에 btrfs가 올바른 선택 일 수 있으며 위의 의견 중 하나는 스왑에 사용하는 방법을 보여줍니다.

우연히, 나는 루트 파일 시스템과 스왑을 포함하여 마지막 날에 일부 Linux 서버를 ZFS에 배치했습니다. 이 작업을 수행하기 전에 조사를 매우 철저히했는데 며칠이 걸렸습니다. 내가 배운 것에 대한 짧은 요약 :

ZFS의 메모리 소비

ZFS의 메모리 소비에 대한 일반적인 오해가 있습니다. ZFS는 일반적으로 많은 메모리를 소비 하지 않습니다 . 실제로 2GB의 RAM이있는 머신에서 TB의 스토리지로 실행됩니다. 중복 제거 를 사용하는 경우에만 (기본적으로 해제되어 있음) 많은 RAM이 필요합니다.

하드웨어 오류 감지 / 수정

SATA, PATA, RAID 또는 기타 오류 감지 / 수정 메커니즘이 데이터 무결성에 충분한 지 여부는 네트워크상의 모든 곳에서 끊임없는 토론과 화염 전쟁을 야기하는 주제입니다. 이론적으로 하드웨어 저장 장치는 발생하는 모든 오류를보고해야하며 모든 수준 (칩셋, 메모리 등)의 데이터 전송 하드웨어도 마찬가지입니다.

글쎄, 그들은 모든 경우에, 또는 놀랍게도 오류에 반응하지 않습니다. 예를 들어 일반적인 RAID5 구성을 살펴 보겠습니다. 일반적으로 한 디스크에 문제가있는 경우 RAID에보고하여 다른 디스크에서 읽을 데이터를 구성하고 전달한 다음 결함이있는 디스크에 다시 씁니다. 데이터를 쓰기 전의 섹터); 동일한 디스크가 너무 많은 오류를보고하면 RAID는 해당 디스크를 오프라인 상태로 만들고 관리자에게 알립니다 (올바르게 구성된 경우).

지금까지는 좋지만 디스크에 오류를보고하지 않고 결함있는 데이터가 디스크에서 나오는 경우가 있습니다 (다음 섹션 참조). 대부분의 RAID는 패리티 정보를 사용하여 이러한 상황을 감지 할 수 있지만 그 반응은 어리 석습니다. 오류를보고하고 데이터 전달을 중지하는 대신 결함이있는 데이터를 기반으로 패리티를 다시 계산 하고 새 패리티를 각각에 기록합니다. 디스크에 결함이있는 데이터를 영원히 올바른 것으로 표시합니다.

합리적인 행동입니까? 내가 아는 한 대부분의 하드웨어 RAID5 컨트롤러와 심지어 Linux의 md RAID가 이런 방식으로 작동합니다.

btrfs의 오류 수정에 대해서는 잘 모르지만, 특히 btrfs의 RAID를 사용하는 경우 문서를 한 번 더주의해서 읽어야합니다.

무음 비트 부패

모든 화염 전쟁과 (의사) 과학적 논의에도 불구하고 : 현실은 대부분 이론과 다르며 이론은 반대라고 말할 수 있지만 무음 비트 썩음은 확실히 발생합니다 (일반적인 봇 썩음은 일반적으로 하드웨어 스토리지의 데이터가 스토리지 장치를 이 데이터를 읽을 때 오류가 발생하지만 전송 경로의 어느 곳에 나이 정의에 플립 비트를 추가합니다.

이런 일이 저의 개인적인 견해는 아닙니다. 적어도 구글, 아마존, CERN은 그 주제에 관한 자세한 백서를 발표했습니다. 논문은 무료로 공개적으로 다운로드 할 수 있습니다. 그들은 수백만 개의 하드 디스크와 수십만 개의 서버 / 저장 장치에 대해 체계적인 실험을 수행했습니다. 데이터 손상이 감지되지 않았거나 문제가 발생하기 전에이를 방지하기 위해해야 ​​할 일을 알고 싶었 기 때문입니다.

요약하면 서버 팜의 데이터가 MTBF 통계 또는 기타 이론에서 예상 한 것보다 훨씬 높은 속도로 손상되었습니다. 상당히 높은 수치를 의미합니다.

따라서 전송 경로의 어느 시점에서나 감지되지 않은 데이터 손상과 같은 자동 비트 썩음은 실제 문제입니다.

데이터 수명

Warren Young은 스왑 데이터의 수명이 짧다고 말할 때 정확합니다. 그러나 다음과 같은 고려 사항을 추가하고 싶습니다. (문서의 의미에서) 데이터 가 스왑 될뿐만 아니라 O / S 또는 기타 실행중인 소프트웨어의 일부일 수도 있습니다 . 내가 스왑에 MP3를 가지고 있다면, 나는 뒤집는 비트로 살 수 있습니다. 프로덕션 httpd 서버 소프트웨어의 일부가 (극단적 인 상황으로 인해) 스왑 상태 인 경우, 결코 감지되지 않는 경우 손상된 코드를 실행하는 플립 비트와 함께 살 수 없습니다.

발문

저에게 ZFS는 이러한 문제를 해결하거나,보다 정확하게는 디스크에서 메모리로 문제를 이동 시켜서 자동 비트 썩음 가능성을 어느 정도 줄입니다. 또한 올바르게 구성된 경우 (예 : RAID 대신 미러), 예상대로 작동하고 결국 쉽게 이해할 수있는 깨끗하고 합리적인 오류 수정 기능을 제공합니다.

이것을 말한 후에는 절대 안전을 얻지 못할 것입니다. 개인적으로 ECC RAM을 디스크보다 더 많이 신뢰하며, ZFS (End-to-End) 체크섬이있는 ZFS는 문제의 가능성을 몇 배나 줄인다고 확신합니다. 나는 것이 결코 하지만, ECC RAM없이 ZFS를 사용하는 것이 좋습니다 없습니다.

면책 조항 : ZFS 공급 업체 또는 개발자와 관련이 없습니다. 이것은 ZFS의 모든 변형 (포크)에 해당됩니다. 나는 방금 과거에 그것을 좋아했습니다 ...