ZFS 숭배 문화

IT 커뮤니티에서 특정 기술이나 제품에 대해 일종의 컬트적 또는 “팬보이”적 사고방식이 발전하는 것은 꽤 흔한 일입니다. 이 반응이 기술과 제품에 대해 왜 일어나는지는 잘 모르겠지만, 그것이 일어난다는 것은 부인할 수 없습니다. 이런 현상이 일어날 것이라고는 결코 생각하지 못했던 한 분야가 파일시스템 영역입니다 – 시스템 컴포넌트 중 가장 “내부적인” 것 중 하나이며, 최근까지 상당히 기술적인 커뮤니티에서도 문자 그대로 아무런 주목을 받지 못했던 것입니다. 솔직히 말해서, Active Directory에서 오는 것과 NTFS에서 오는 것의 차이를 오해하는 것은 거의 보편적입니다. 파일시스템은 단순히 무시됩니다. Windows NT 4가 출시되고 NTFS가 유일하게 실행 가능한 옵션이 된 이후로, 파일시스템이 운영체제의 내재적 컴포넌트가 아니며 파일 스토리지에 대한 다른 옵션이 있을 수 있다는 생각은 거의 사라졌습니다. 최근까지는 그랬습니다.

이런 현상이 어느 정도 일어나지 않았던 커뮤니티가 하나 있었다면 Linux 커뮤니티였지만, 거기서도 Ext2와 그 후손들이 마인드쉐어를 완전히 장악하여 대체 파일시스템들이 널리 사용 가능했음에도 사이드라인으로 밀려났고, 역사적으로 XFS만이 어느 정도 주목을 받았지만 그것도 매우 적었습니다.

최근에 정말 이상한 행동이 나타난 곳은 Oracle의 ZFS 파일시스템을 둘러싸고입니다. ZFS는 원래 Solaris 운영체제와 X4500 “Thumper” 오픈 스토리지 플랫폼(Oracle 인수 이전 Sun의 주도 하에 처음 개발)을 위해 개발되었습니다. ZFS가 출시된 당시(9년 전)에 경쟁 파일시스템들은 앞으로 몇 년에 걸쳐 만들어질 것으로 예상되는 대형 디스크 어레이를 처리하기 위한 준비가 거의 되어 있지 않았습니다. ZFS는 이를 처리하도록 설계되어 대규모 파일시스템의 시대를 열었습니다. 당시 대부분의 파일시스템과 마찬가지로 ZFS는 단일 운영체제로만 제한되었기 때문에 파일시스템 설계의 큰 도약으로 널리 인정받았음에도 스토리지 세계에서는 거의 파문을 일으키지 못했고, “시스템” 세계에서는 더욱더 그랬습니다. Solaris 관리자들조차 일반적으로 꽤 오랫동안 단순히 흥미로운 포인트로만 여겼으며, 대부분 오랫동안 사용해온 검증된 UFS를 계속 사용하기로 선택했습니다.

ZFS는 진정으로 획기적인 파일시스템이었으며 저는 그것의 훌륭한 지지자였고 지금도 그렇습니다. 하지만 ZFS가 무엇을 했는지, 목표가 무엇인지, 그 목표가 왜 중요했는지, 오늘날 우리에게 어떻게 적용되는지를 이해하는 것이 매우 중요합니다. ZFS의 복잡성은 파일시스템이 어떻게 작동하는지, 언제 사용하는 것이 적절한지에 대한 많은 혼란과 오해를 낳았습니다.

ZFS의 주요 목표는 매우 큰 디스크 어레이에 잘 확장할 수 있는 파일시스템을 만드는 것이었습니다. 도입 당시 ZFS가 달성 가능했던 규모는 다른 파일시스템에서는 전례가 없었지만 파일시스템이 그렇게 크게 성장할 실제적 필요는 없었습니다. 그 필요가 생길 즈음에는 NTFS, XFS, Ext3 및 기타 여러 파일시스템들이 해당 필요를 수용하도록 확장되었습니다. ZFS는 분명히 더 큰 파일시스템 처리를 위한 선두에 섰지만 곧 많은 다른 것들이 뒤따랐습니다.

ZFS는 모든 대형 UNIX 시스템과 마찬가지로 하드웨어 RAID가 없는 Solaris 세계에서 유래했기 때문에 소프트웨어 RAID를 사용해야 했습니다. Solaris는 항상 자체 서브시스템으로서 소프트웨어 RAID를 사용할 수 있었습니다. ZFS에 직접 새로운 소프트웨어 RAID 구현을 내장하기로 결정했습니다. 이를 통해 RAID 레이어와 파일시스템 모두를 위한 단일 도구 세트를 통한 간소화된 관리가 가능해집니다. 종종 믿어지는 것처럼 ZFS에 중요한 변화나 이점을 도입하지는 않았으며, 단순히 소프트웨어 RAID 레이어의 인터페이스를 자체 명령 세트에서 ZFS 명령 세트의 일부로 전환한 것입니다.

ZFS의 RAID 구현은 패리티 RAID 레벨에 가변 폭 스트라이프를 도입했습니다. 이 혁신은 “쓰기 홀(write hole)”로 알려진 사소한 패리티 RAID 위험을 해결했습니다. 이 혁신은 매우 훌륭했지만 신뢰할 수 있는 패리티 RAID의 시대가 끝나가고 있을 때 매우 늦게 도달했으며, 쓰기 홀 문제는 이미 배터리 백업 어레이 캐시의 사용과, 거의 같은 시기에 비휘발성 어레이 캐시를 통해 그 위협으로 일반적으로 고려되지 않아 패리티 어레이의 언급되지 않은 “배경 소음” 위험으로 간주되었습니다. 정전을 피하면 쓰기 홀도 피할 수 있습니다. ZFS는 이 문제를 해결해야 했는데, 소프트웨어 RAID로서 하드웨어 RAID보다 쓰기 홀에 더 큰 위험에 노출되어 있었기 때문입니다. 하드웨어 RAID는 어레이에 대한 전원 보호의 추가 레이어 가능성을 제공하지만 소프트웨어 RAID에는 전원 손실로부터 보호되는 캐시의 기회가 없습니다.

ZFS가 의도치 않게 만든 진짜 “혁신”은 1, 5, 6, 10의 일반적인 RAID 레벨만 구현하는 대신 이 레벨들에 자체 명명 규칙으로 “브랜딩”했다는 것입니다. RAID 5는 RAIDZ로 알려져 있습니다. RAID 6는 RAIDZ2로 알려져 있습니다. RAID 1은 단순히 미러링으로 알려져 있습니다. 등등. 이것은 당시에는 어리석고 불필요하게 혼란스럽다고 널리 여겨졌지만, 결과적으로 그 혼란이 수년 후 ZFS 부활의 초석이 되었습니다.

ZFS가 나중에 RAID 7(RAID 7.3이라고도 알려진) 삼중 패리티 RAID 시스템의 업계 최초 프로덕션 구현을 추가했으며 이를 RAIDZ3로 브랜딩했다는 점을 주목해야 합니다. 이 후기 추가는 성능을 희생하면서도 최고의 용량을 유지하며 극도로 안전해야 하는 대규모 어레이에 중요한 혁신입니다. 이것은 ZFS의 고유한 기능으로 남아 있지만 드물게 사용됩니다.

스토리지 스택을 통합하고 스토리지의 모든 측면을 관리하는 단일 명령 세트를 사용하려는 정신에서 논리 볼륨 관리 기능도 ZFS에 통합되었습니다. ZFS가 특정 서클에서 논리 볼륨 관리를 도입했다고 잘못 믿어지지만, AIX, Linux, Windows, 심지어 Solaris 자체를 포함한 거의 모든 엔터프라이즈 플랫폼은 이미 여러 해 동안 논리 볼륨 관리 기능을 가지고 있었습니다. ZFS는 새로운 패러다임을 도입하기 위해 이것을 한 것이 아니라 단순히 관리를 통합하고 세 가지 주요 스토리지 레이어(RAID, 논리 볼륨 관리 및 파일시스템)를 모두 관리하기 더 쉽고 스택 위아래로 내재적 통신을 제공할 수 있는 단일 엔티티로 감싸기 위한 것이었습니다. 이 방법에는 장단점이 있으며 거의 10년이 지난 후에도 업계의 의견은 형성되지 않았습니다.

세 시스템을 하나로 통합한 가장 중요한 측면 중 하나는 이제 매우 혼란스러운 제품을 논의해야 한다는 것입니다. ZFS는 파일시스템이지만 파일시스템만은 아닙니다. 논리 볼륨 관리자이지만 논리 볼륨 관리자만도 아닙니다. 사람들은 ZFS를 파일시스템이라고 부르는데, 이것이 주된 기능이지만 파일시스템 그 이상이라는 것이 매우 혼란스러울 수 있으며 다른 스토리지 시스템과의 비교를 어렵게 만듭니다. 당시에는 이 혼란이 예상되지 않았다고 생각합니다.

이 혼란스러운 통합으로 인한 결과는 ZFS가 종종 XFS나 Ext4와 같은 다른 파일시스템과 비교된다는 것입니다. 그러나 ZFS는 완전한 스택이고 XFS는 스택의 한 측면에 불과하기 때문에 이것은 혼란스럽습니다. ZFS는 XFS 단독과 비교하기보다는 MD(Linux 소프트웨어 RAID)/LVM/XFS 또는 SmartArray(HP 하드웨어 RAID)/LVM/XFS와 비교하는 것이 더 적절합니다. 그렇지 않으면 ZFS에는 XFS에 없는 기능이 가득 찬 것처럼 보이지만, 실제로는 의미론적 승리에 불과합니다. ZFS 지지자들이 자주 선전하는 기능 대부분은 ZFS에서 유래하지 않았으며 ZFS가 존재하기 훨씬 전부터 대체 파일시스템에서 일반적으로 사용 가능했습니다. 하지만 “당신의 파일시스템이 그 기능을 지원합니까”라고 비교하기 어렵습니다. 왜냐하면 대답이 “아니요... RAID 또는 논리 볼륨 관리자가 그것을 합니다”이기 때문입니다. 그리고 실제로 RAIDZ를 제공하는 것은 파일시스템으로서의 ZFS가 아니라 소프트웨어 RAID 서브시스템으로서의 ZFS입니다.

매우 큰 파일시스템을 우아하게 처리하기 위해 데이터 무결성 기능이 ZFS에 내장되었는데, 여기에는 파일시스템 전체에 걸쳐 체크섬 또는 해시 검사가 포함되어 손상된 파일을 수리하기 위해 내장된 소프트웨어 RAID를 활용할 수 있었습니다. 이것은 미래 ZFS 파일시스템의 예상 크기 때문에 필요하다고 여겨졌습니다. 파일시스템 손상은 거의 발생하지 않는 현상이지만 파일시스템이 크기가 커짐에 따라 위험도 증가합니다. ZFS의 이 덜 알려진 기능은 아마도 ZFS의 가장 뛰어난 기능일 것입니다.

ZFS는 또한 파일시스템 검사가 처리되는 방식을 변경했습니다. ZFS가 매우 큰 파일시스템에서 사용될 것이라는 가정 때문에 부팅 시 파일시스템 검사가 완료되기까지 불가능할 만큼 오래 걸릴 수 있다는 실질적인 우려가 있었고, 그래서 대안적인 전략이 고안되었습니다. 재부팅 시까지 검사를 기다리는 대신 시스템이 실행 중인 동안 스크러빙 프로세스를 실행하여 유사한 검사를 수행해야 합니다. 이는 시스템이 실행 중일 때 더 많은 시스템 오버헤드를 필요로 하지만 예기치 않은 재시작으로부터 더 빨리 복구할 수 있습니다. 절충이지만 널리 매우 긍정적으로 평가됩니다.

ZFS는 논리 볼륨 레이어에서 강력한 스냅샷 기능을 가지고 있으며 RAID 레이어에서 매우 강력한 캐싱 메커니즘을 구현하여 ZFS를 많은 사용 사례에 대한 우수한 선택으로 만들었습니다. 이러한 기능들은 ZFS에서 고유하지 않으며 ZFS보다 오래된 시스템에서 널리 사용 가능합니다. 하지만 각각의 매우 좋은 구현이며 ZFS의 특성으로 인해 매우 잘 통합되어 있습니다.

한때 ZFS는 오픈 소스였으며 그 기간 동안 그 코드는 ZFS 라이선스와 호환되었기 때문에 Apple의 Mac OSX와 FreeBSD 운영체제의 일부가 되었습니다. Linux는 라이선스 관련 문제로 그 당시 ZFS를 받지 못했습니다. ZFS 라이선스가 Linux에서 이를 제약 없이 사용할 수 있도록 허용했다면 Linux 환경은 오늘날 매우 다를 것입니다. Mac OSX는 결국 ZFS를 그 환경에서 정당화할 만큼 충분한 이점이 없다고 보고 ZFS를 제거했습니다. FreeBSD는 ZFS를 고수했으며 시간이 지남에 따라 UFS도 여전히 많이 사용되지만 플랫폼에서 가장 인기 있는 파일시스템이 되었습니다. Oracle은 Sun 인수 후 ZFS의 소스를 폐쇄하여 FreeBSD가 Oracle이 내부적으로 Solaris를 위해 ZFS를 계속 개발하는 동안 ZFS 버전에 대한 지속적인 업데이트 없이 남게 되었습니다.

오늘날 Solaris는 오픈 소스 커뮤니티와 분리된 이후 몇 가지 업데이트가 적용된 원래 ZFS 구현을 계속 사용하고 있습니다. FreeBSD와 다른 시스템들은 코드가 폐쇄 소스가 되었을 때의 상태로 ZFS를 계속 사용하며 Oracle의 최신 업데이트에 더 이상 접근할 수 없었습니다. 결국 방치된 오픈 소스 ZFS 코드베이스를 업데이트하는 작업이 진행되었으며 현재는 OpenZFS로 알려져 있습니다. OpenZFS는 아직 초기 단계이며 아직 실질적인 영향을 미치지 못했지만 오픈 소스 공간에서 ZFS 플랫폼을 활성화할 잠재력이 있습니다. 하지만 현재 OpenZFS는 여전히 ZFS에 뒤처져 있습니다.

이 분야에서 지난 몇 년간의 오픈 소스 개발은 Linux에서 기본적으로 개발되고 많은 주요 운영체제 벤더의 폭넓은 지원을 받고 있는 ZFS의 새로운 경쟁자인 BtrFS에 더 집중되어 왔습니다. BtrFS는 매우 초기 단계이지만 구현된 기능에서 ZFS와의 기능 동등성에 도달하기 위해 큰 진전을 이루고 있으며 큰 포부를 가지고 있습니다. ZFS의 폐쇄 소스 특성으로 인해 시장 모멘텀의 이점도 있습니다. BtrFS는 ZFS와 마찬가지로 Oracle에 의해 시작되었으며 Oracle에서도 ZFS의 대체품으로서 미래를 바라보는 Oracle의 시각으로 널리 여겨지고 있습니다. 현재 BtrFS는 이미 ZFS와 마찬가지로 파일시스템, 논리 볼륨 관리 및 소프트웨어 RAID 레이어를 통합하고, 파일시스템 무결성을 위한 체크섬을 구현하며, ZFS보다 더 크게 확장하고(같은 절대 한계이지만 더 많은 파일을 처리), 쓰기 시 복사(CoW) 스냅샷 등을 지원합니다.

ZFS는 의심할 여지 없이 전성기에 놀라운 파일시스템이었으며 오늘날도 선도적인 위치를 유지하고 있습니다. 저는 2005년에도 지지자였고 지금도 여전히 강하게 믿습니다. 하지만 ZFS 커뮤니티가 아무런 도움도 되지 않고 ZFS를 언급하는 것이 거의 부정적으로 보이게 만드는 열정과 광신주의를 갖게 되는 것을 보는 것이 슬펐습니다 – ZFS가 주로 잘못된 이유로 선택되기 때문입니다: 주로 그 기능들이 다른 곳에는 존재하지 않는다는 믿음, RAID가 항상 적용되는 위험과 한계에 적용되지 않는다는 믿음, 또는 설계된 것과 다른 목적(주로 성능)을 위해 설계되었다는 믿음. 그리고 ZFS가 좋은 선택일 때도 잘못된 가정을 기반으로 종종 잘못 구현됩니다.

ZFS는 물론 비난받아야 할 것이 없습니다. 제가 파악할 수 있는 한, 그 기업 지원자들이나 오픈 소스 개발자들도 마찬가지입니다. ZFS가 잘못된 방향으로 간 것처럼 보이는 곳은 최근에야 ZFS를 알게 된 느슨하고 비공식적인 커뮤니티에서입니다. 이들은 종종 최근에야 발견했기 때문에 새롭거나 “차세대”라고 믿습니다. 제가 본 바에 따르면 이것은 Solaris나 FreeBSD 채널을 통해서가 아니라 거의 독점적으로 FreeNAS나 NAS4Free와 같은 패키지형 “NAS OS”를 사용하려는 소규모 비즈니스를 통해서이며, 이들은 UNIX OS에 익숙하지 않습니다. 주로 깊은 UNIX 기술도 스토리지 기술도 없고, 결과적으로 Windows 외의 파일시스템 세계에 대한 폭넓은 노출도 없고 논리 볼륨 관리 및 RAID, 특히 소프트웨어 RAID에 대한 경험이 전혀 없거나 거의 없는 IT 부서가 패키지형 NAS OS를 사용하는 것이 ZFS를 거의 의심할 수 없는 무오류적 지위를 가진 것으로 받아들이는 “신화” 문화로 이어지는 것 같습니다.

이 컬트적 추종과 ZFS에 대한 일반적인 오해는 종종 ZFS의 오용 또는 나쁜 가정에 기반한 일련의 의사결정으로 이어져 크게 잘못된 방향으로 이끌 수 있습니다.

이 분야에서 가장 놀라운 변화 중 하나는 하드웨어 RAID에서 소프트웨어 RAID로의 추종 변화입니다. 전통적으로 소프트웨어 RAID는 Windows 관리자 커뮤니티에서 근거 없이 기피되었습니다 – Windows 관리자와 소규모 비즈니스는 더 큰 UNIX 서버에 익숙하지 않아 하드웨어 RAID가 실제로는 대규모 시스템이 항상 소프트웨어 RAID를 사용했음에도 불구하고 어디에나 있다고 믿었습니다. 하드웨어 RAID는 업계 전반에 걸쳐 거의 필수품으로 여겨졌고 소프트웨어 RAID는 완전히 배제되었습니다. 그 동일한 청중이 이제 “ZFS 숭배” 운동에 직면하여 하드웨어 RAID는 나쁘고 ZFS의 소프트웨어 RAID만이 유일하게 실행 가능한 옵션이라고 믿으며 정반대의 방식으로 반응합니다. 이 변화는 극적이며 두 접근 방식 모두 유효하지 않습니다 – 하드웨어와 소프트웨어 RAID 모두, 많은 구현에서 모두 매우 유효한 옵션이며 ZFS를 사용하더라도 하드웨어 RAID를 사용하는 것이 쉽게 적절할 수 있습니다.

ZFS는 파일시스템 중 최고 성능 옵션이라고 믿어지기 때문에 종종 선택되지만 이것은 ZFS의 주요 설계 목표가 아니었습니다. ZFS가 그렇게 크게 확장하고 스토리지의 여러 다른 측면을 처리하도록 하는 기능들은 사실 높은 성능을 갖추기 매우 어렵게 만듭니다. ZFS는 생성 당시 같은 시스템에서 실행되던 오래된 UFS만큼 빠를 것으로도 예상되지 않았습니다. 그러나 이것은 종종 모든 현대 파일시스템이 매우 빠르고 파일시스템 속도가 거의 중요한 요소가 아니라는 사실에 부차적입니다 – 특히 매우 대규모의 최고급 스토리지 시스템 외에서는 더욱 그렇습니다.

Phoronix가 2013년에 Linux에서 10개의 파일시스템을 연구한 흥미로운 연구에서 워크로드별로 파일시스템 간에 엄청난 차이가 있었지만 전체 성능에서 명확한 승자는 없었습니다. 이 연구가 결정적으로 보여준 것은 워크로드를 파일시스템에 맞추는 것이 가장 중요한 선택이며, ZFS는 더 현대적인 구현에서도 모든 주류 파일시스템 중 느린 쪽에 속하며, 워크로드에 대한 매우 깊은 이해 없이 성능상의 이유로 파일시스템을 선택하면 예측 불가능한 성능이 나타날 것이라는 점입니다 – 성능이 중요한 요소라면 어떤 파일시스템도 맹목적으로 선택해서는 안 됩니다. 슬프게도 테스트가 Linux에서 수행되었기 때문에 특히 Solaris와 FreeBSD에서 ZFS의 주요 경쟁자인 UFS가 없었고 Mac OSX의 HFS+도 없었습니다.

하드웨어 RAID에서 소프트웨어 RAID로 이동하면 UNIX에 경험이 없는 업체에게도 종종 예상치 못한 추가 위험이 따릅니다. ZFS가 핫 스왑을 허용하지만, 핫 스왑이 주로 소프트웨어가 아닌 하드웨어의 기능이라는 것이 종종 잊혀지며, 블라인드 스왑핑(운영체제에서 먼저 오프라인 없이 하드 드라이브를 제거하는 것)이 핫 스왑과 동의어가 아니라는 것도 널리 알려지지 않았습니다. 이는 호환성, 핫 스왑, 블라인드 스왑핑을 투명하게 처리했던 하드웨어 RAID의 전통에서 훨씬 더 많은 계획, 조정 및 시스템에 대한 이해가 필요한 소프트웨어 RAID 시스템으로 이동하는 업체에게 재앙으로 이어질 수 있습니다.

ZFS에 대한 덜 알려졌지만 여전히 흔한 오해는 ZFS가 OCFS, VxFS 및 GFS2와 같이 공유 DAS 또는 SAN 시나리오에서 사용하기에 적합한 클러스터 파일시스템이라는 것입니다. ZFS는 클러스터 파일시스템이 아니며 그 공간에서 모든 일반적인 경쟁자와 동일한 한계를 공유합니다.

ZFS는 훌륭한 선택이 될 수 있지만 유일한 선택과는 거리가 멉니다. ZFS는 그와 관련된 운영체제 제한 사항을 포함하여 큰 단점들을 가지고 있으며, 많은 이점이 있지만 ZFS에 고유한 것은 거의 없고 어떤 업체도 그 모든 이점으로부터 이익을 얻는 경우는 매우 드뭅니다. 어떤 기술과 마찬가지로 절충해야 할 사항이 있습니다. 하나의 크기가 모두에게 맞지 않습니다. ZFS가 적합한 경우를 아는 핵심은 ZFS가 무엇인지, 무엇이 고유하고 무엇이 고유하지 않은지, 설계 목표가 무엇인지, 스토리지 스택을 순수 파일시스템과 비교하면 왜 오해의 소지가 있는 결과가 나오는지, 그리고 어떤 내재적 한계가 있는지를 이해하는 것입니다.

ZFS는 Solaris나 FreeBSD가 선택된 운영체제인 경우 핵심 고려 사항이자 일반적인 선택입니다. 드문 예외를 제외하고 운영체제는 ZFS를 위해 선택되어서는 안 되며, 대신 ZFS는 운영체제가 선택될 때 종종(항상은 아닌) 선택되어야 합니다. 운영체제가 가장 드문 경우를 제외한 모든 상황에서 파일시스템 선택을 이끌어야 합니다. 운영체제 선택은 파일시스템 선택보다 극적으로 더 중요합니다.

ZFS는 Linux에서 사용할 수 있지만 엔터프라이즈 옵션으로 여겨지지 않고 Red Hat, Suse 또는 Canonical과 같은 엔터프라이즈 벤더가 Linux에서 ZFS를 지원하지 않으며 Linux에는 이미 훌륭한 대안이 있기 때문에 실험을 위한 취미 시스템 정도로만 여겨집니다. 언젠가 ZFS가 Linux에서 일급 파일시스템으로 승격될 수도 있지만 BtrFS가 이미 메인라인 커널에 진입했고 여러 주요 벤더의 프로덕션 릴리스에 포함되었기 때문에 예상되지 않습니다.

ZFS는 대다수의 Solaris 및 FreeBSD 배포에서 볼 수 있지만, 이는 주로 그 인스턴스에서 분명히 우수한 선택이거나 비판적으로 평가되었기 때문이 아니라 기본 파일시스템의 위치로 이동했기 때문입니다. ZFS는 기본적으로 지원되는 곳에서 범용 파일시스템으로 완벽하게 적합합니다.

ZFS의 주요 사용 사례는 무엇입니까?

ZFS의 설계 목표와 주요 사용 사례는 다른 서버에 공유 스토리지를 제공하거나 로컬에 설치된 애플리케이션을 위한 대규모 데이터 저장소로서 Solaris 및 FreeBSD 오픈 스토리지 시스템입니다. 이러한 경우에 ZFS의 확장성과 데이터 무결성에 대한 초점이 정말 빛을 발합니다. ZFS는 대규모 및 엔터프라이즈 규모 업체에 크게 기울어져 있으며, Solaris 및 FreeBSD 기술과 대규모 스토리지 요구가 드문 중소기업 공간에서의 적용 가능성에서는 일반적으로 멀어집니다.

참조: http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1