ZFS

ZFS
기타 용도는 ZFS(동음이의)를 참조하십시오.
ZFS
개발자Sun Microsystems 원래 오라클 Corporation 2010년부터 OpenZ2013년 이후 FS
변종Oracle ZFS, OpenZFS
소개했다2005년 11월, 18년 전(2005-11년) OpenSolaris 사용
구조물들
디렉토리 내용확장 가능 해시 테이블
한계
최대 볼륨 크기256조 요비바이트(2바이트128)[1]
최대 파일 크기16 엑스비바이트(2바이트64)
최대 파일 수
  • 디렉토리별48: 2
  • 파일 시스템당: 무제한[1]
최대 파일 이름 길이255 ASCII 문자(유니코드와 같은 멀티바이트 문자 표준의 경우 더 적음)
특징들
포크예("확장 특성"이라고 하지만 이 특성은 본격적인 스트림입니다.)
특성POSIX, 확장 속성
파일 시스템
허가 사항		유닉스 권한, NFSv4 ACL
투명
압축의		네.
투명
암호화		네.
데이터 중복제거네.
쓰기 시 복사네.
다른.
지원됨
운영 체제

ZFS(이전: Zettabyte File System)는 볼륨 관리 기능을 갖춘 파일 시스템입니다. 2001년 Sun Microsystems Solaris 운영 체제의 일부로 시작되었습니다. ZFS를 포함한 Solaris의 대규모 부분은 2005년부터 약 5년 동안 OpenSolaris로 오픈 소스 라이센스로 공개되었다가 2009-2010년 Oracle Corporation이 Sun을 인수할 때 비공개 소스 라이센스로 공개되었습니다. 2005년부터 2010년까지 ZFS의 오픈 소스 버전은 Linux, Mac OS X(MacZFS로 계속됨) 및 FreeBSD로 이식되었습니다. 2010년, Illumos 프로젝트는 오픈 소스 프로젝트로 개발을 계속하기 위해 ZFS를 포함한 OpenSolaris의 최근 버전을 제공했습니다. 2013년 오픈ZFS는 오픈 소스 ZFS의 개발을 조정하기 위해 설립되었습니다.[3][4][5] 오픈ZFS는 핵심 ZFS 코드를 유지 및 관리하는 반면, ZFS를 사용하는 조직은 ZFS가 시스템 내에 통합되는 데 필요한 특정 코드 및 검증 프로세스를 유지합니다. 오픈ZFS는 유닉스 계열 시스템에서 널리 사용됩니다.[6][7][8]

개요

저장된 데이터의 관리에는 일반적으로 두 가지 측면이 포함됩니다. 하나 이상의 블록 저장 장치(하드 드라이브 및 SD 카드 등)의 물리적 볼륨 관리에는 운영 체제에서 볼 수 있는 논리적 블록 장치(종종 볼륨 관리자, RAID 컨트롤러, 어레이 관리자, 또는 적합한 장치 드라이버); 및 이러한 논리 블록 장치(파일 시스템 또는 다른 데이터 저장소)에 저장된 데이터 및 파일의 관리.

예: 하드 드라이브 2개와 SSD 캐싱 디스크로 구성된 RAID 어레이는 데스크탑 컴퓨터에 내장된 칩셋 및 펌웨어의 일부인 Intel의 RST 시스템에 의해 제어됩니다. Windows 사용자는 이러한 데이터를 NTFS 형식의 드라이브가 포함된 단일 볼륨으로 간주하며, NTFS는 필요한 조작(캐시 드라이브에서 읽기/쓰기, 디스크에 오류가 발생할 경우 RAID 어레이 재구축 등)을 인식하지 못합니다. 개별 장치를 관리하고 단일 장치로 표시하는 것은 해당 장치에 저장된 파일을 관리하는 것과 구별됩니다.

ZFS는 대부분의 다른 스토리지 시스템과 달리 이 두 가지 역할을 모두 통합하고 볼륨 관리자와 파일 시스템의 역할을 모두 수행하기 때문에 특이합니다. 따라서 물리적 디스크와 볼륨(상태, 상태 및 볼륨에 대한 논리적 배열 포함) 및 볼륨에 저장된 모든 파일에 대해 완벽하게 파악할 수 있습니다. ZFS는 물리적 오류, 하드웨어 또는 운영 체제의 잘못된 처리, 또는 시간이 지남에 따라 발생할 수 있는 비트 로트 이벤트 및 데이터 손상으로 인해 디스크에 저장된 데이터가 손실되지 않도록(해당 하드웨어에 따라) 설계되었습니다. 스토리지 시스템을 완벽하게 제어함으로써 파일 관리 또는 디스크 관리와 관련된 모든 단계가 스토리지 컨트롤러 카드와 별도의 볼륨 및 파일 관리자가 달성할 수 없는 방식으로 검증, 확인, 수정 및 최적화됩니다.

또한 ZFS에는 FreeB에서 설명하는 스냅샷 클로닝을 포함하여 데이터셋 및 풀 레벨 스냅샷 및 복제를 위한 메커니즘이 포함되어 있습니다.SD 문서는 "스냅샷 기능이 없는 다른 파일 시스템에도 부족한" 기능을 갖춘 "가장 강력한 기능" 중 하나입니다.[9] 성능 저하 없이 매우 많은 수의 스냅샷을 생성할 수 있으므로 위험한 시스템 작업 및 소프트웨어 변경 전에 스냅샷을 사용하거나 전체 프로덕션("라이브") 파일 시스템을 한 시간에 여러 번 완전히 스냅샷하여 사용자 오류 또는 악의적인 작업으로 인한 데이터 손실을 줄일 수 있습니다. 스냅샷을 "라이브" 상태로 롤백하거나 매우 큰 파일 시스템에서도 이전 파일 시스템 상태를 볼 수 있으므로 공식적인 백업 및 복원 프로세스에 비해 비용을 절감할 수 있습니다.[9] 스냅샷을 복제하여 새로운 독립 파일 시스템을 형성할 수도 있습니다. 또한 ZFS는 풀 레벨 스냅샷("체크포인트"라고 함)을 생성할 수 있으며, 이를 통해 풀 전체 구조에 영향을 미칠 수 있는 작업을 롤백하거나 전체 데이터셋을 추가하거나 제거할 수 있습니다.

역사

참고 항목: Solaris(운영 체제), OpenSolaris, OpenIndiana, Illumos 및 Sun Microsystems

2004-2010: Sun Microsystems 개발

1987년, AT&T Corporation과 Sun은 당시 시장에서 가장 인기 있는 유닉스 변종을 합병하는 프로젝트를 공동으로 진행하고 있다고 발표했습니다. Berkeley Software Distribution, UNIX System V 및 Xenix. 이는 유닉스 시스템 V 릴리즈 4(SVR4)가 되었습니다.[10] 이 프로젝트는 솔라리스라는 이름으로 출시되었으며, 솔라리스는 선OS 4의 후속작이 되었습니다(비록 선OS 4.1.x 마이크로 릴리스는 소급하여 솔라리스 1로 명명되었습니다).[11]

ZFS는 Jeff Bonwick, Bill Moore,[12] Matthew Ahrens가 이끄는 Sun의 팀에 의해 설계 및 구현되었습니다. 2004년 9월 14일에 [13]발표되었으나 2001년부터 개발이 시작되었습니다.[14] ZFS용 소스 코드는 2005년[15] 10월 31일 Solaris 개발의 메인 트렁크에 통합되었으며 2005년 11월 16일 OpenSolaris 빌드 27의 일부로 개발자들을 위해 출시되었습니다. 2006년 6월, Sun은 ZFS가 Solaris 10의 메인스트림 6/06 업데이트에 포함되었다고 발표했습니다.[16]

Solaris는 원래 독점 소프트웨어로 개발되었지만 Sun Microsystems는 오픈 소스 소프트웨어의 초기 상업적 제안자였으며 2005년 6월 CDDL 라이선스로 Solaris 코드베이스의 대부분을 공개하고 OpenSolaris 오픈 소스 프로젝트를 설립했습니다.[17] Solaris 106/06 ("U2")에서 Sun은 향후 5년 동안 ZFS 파일 시스템을 추가하고 새로운 기능으로 ZFS를 자주 업데이트했습니다. ZFS는 이 오픈 소스 라이센스로 리눅스, Mac OS X(MacZFS로 계속됨), FreeBSD로 이식되었습니다.

한때 이 이름은 "제타바이트 파일 시스템"의 약자로 알려졌지만,[18] 2006년에 이르러 이 이름은 더 이상 약어로 여겨지지 않게 되었습니다.[19] ZFS 파일 시스템은 최대 256,000,000,000,000,000 제타바이트(ZB)를 저장할 수 있습니다.

2007년 9월, NetApp은 ZFS가 Write Anywhere File Layout에 대한 NetApp의 특허 일부를 침해했다고 주장하며 Sun을 고소했습니다. 선은 같은 해 10월에 그 반대를 주장하며 맞소송을 제기했습니다. 소송은 2010년에 미공개 합의로 종결되었습니다.[20]

2010-현재: Oracle, OpenZFS에서의 개발

주요 기사: Oracle ZFS § 기록 및 OpenZFS §의 역사

포트 버전의 ZFS는 2005년부터 등장하기 시작했습니다. 2010년 오라클이 선을 인수한 후, 오라클의 ZFS 버전은 폐쇄형 소스가 되었고 오픈 소스 버전의 개발은 OpenZ가 조정하여 독립적으로 진행되었습니다.2013년 FS.

특징들

요약

ZFS에 특화된 기능의 예는 다음과 같습니다.

  • 데이터를 장기적으로 저장할 수 있도록 설계되었으며, 데이터 손실이 없고 구성성이 높은 데이터스토어 크기를 무한대로 확장할 수 있습니다.
  • 모든 데이터와 메타데이터를 계층적으로 체크섬하여 전체 스토리지 시스템이 사용 중인지 확인하고 올바르게 저장되었는지 확인하거나 손상된 경우 복구할 수 있습니다. 체크섬은 블록 자체가 아니라 블록의 상위 블록과 함께 저장됩니다. 이는 체크섬이 데이터와 함께 저장되는 많은 파일 시스템과 대조되므로 데이터가 손실되거나 손상되면 체크섬도 손실되거나 부정확해질 가능성이 있습니다.
  • 중요한 파일 및 구조의 데이터 손상으로부터 복구할 수 있는 기능을 향상시키기 위해 사용자가 지정한 수의 데이터 또는 메타데이터 복사본 또는 선택된 유형의 데이터를 저장할 수 있습니다.
  • 파일 시스템 및 데이터에 대한 최근 변경 사항을 자동으로 롤백합니다. 경우에 따라 오류 또는 불일치가 발생할 수 있습니다.
  • 데이터를 재구성할 수 있는 모든 오류에 대해 데이터 불일치 및 쓰기 실패를 자동으로 자동화 및 (일반적으로) 자동화된 자동 자기 복구 기능을 제공합니다. 각 블록의 상위 블록에 저장된 오류 탐지 및 수정 체크섬, 디스크에 저장된 여러 개의 데이터 복사본(체크섬 포함), 발생했어야 하지만 발생하지 않은 쓰기(전원 장애 후)에 대한 쓰기 의도, RAID/RAID-Z의 패리티 데이터를 사용하여 데이터를 재구성할 수 있습니다. 디스크 및 볼륨, 미러링된 디스크 및 볼륨의 데이터 복사본.
  • 표준 RAID 레벨 및 추가 ZFS RAID 레이아웃("RAID-Z")을 기본적으로 처리합니다. RAID-Z는 효율성을 위해 필요한 디스크에만 스트라이프 데이터를 레벨링하고(많은 RAID 시스템이 모든 디바이스에 걸쳐 무차별적으로 스트라이프), 체크섬을 통해 일관성이 없거나 손상된 데이터를 결함이 있는 블록에 재구축하는 것을 최소화할 수 있습니다.
  • 일반적으로 볼륨 관련 작업인 계층화된 스토리지 및 캐싱 장치를 기본적으로 처리합니다. ZFS는 파일 시스템도 이해하고 있기 때문에 파일 관련 지식을 사용하여 별도의 장치로는 알 수 없는 계층화된 스토리지 처리를 알려주고 통합하며 최적화할 수 있습니다.
  • 볼륨과 파일 처리를 통합하여 효율적인 스냅샷 및 백업/복제를 기본적으로 처리할 수 있습니다. 관련 도구는 낮은 수준으로 제공되며 활용을 위해서는 외부 스크립트와 소프트웨어가 필요합니다.
  • 네이티브 데이터 압축 및 중복제거 기능. 하지만 후자는 대부분 RAM으로 처리되며 메모리가 부족합니다.
  • RAID 어레이의 효율적인 재구축— RAID 컨트롤러는 종종 전체 디스크를 재구축해야 하지만, ZFS는 디스크와 파일 지식을 결합하여 재구축이 실제로 없거나 손상된 데이터로 제한하여 재구축 속도를 크게 높일 수 있습니다.
  • 다른 많은 시스템에 영향을 미치는 RAID 하드웨어 변경에도 영향을 받지 않습니다. 많은 시스템에서 RAID 카드와 같은 자체 RAID 하드웨어에 장애가 발생하거나 데이터를 다른 RAID 시스템으로 이동할 경우 파일 시스템에 원래 RAID 하드웨어에 있던 정보가 부족하여 RAID 어레이의 데이터를 관리하는 데 필요합니다. 이는 거의 동일한 하드웨어를 획득하여 "스텝 스톤"으로 사용할 수 없는 한 데이터가 완전히 손실될 수 있습니다. ZFS는 RAID 자체를 관리하므로 ZFS 풀을 다른 하드웨어로 마이그레이션하거나 운영 체제를 재설치할 수 있으며, RAID-Z 구조와 데이터를 인식하여 ZFS에서 즉시 액세스할 수 있습니다.
  • 캐시에서 발견되었을 수도 있지만 최근에 폐기된 데이터를 식별할 수 있습니다. 이를 통해 ZFS는 나중에 사용할 수 있도록 캐싱 결정을 재평가하고 매우 높은 캐시 적중률(ZFS 캐시 적중률은 일반적으로 80% 이상)을 지원합니다.
  • 대체 캐싱 전략은 데이터 처리 지연을 유발하는 데이터에 사용할 수 있습니다. 예를 들어, 스토리지 시스템의 속도를 늦출 수 있는 동기식 쓰기는 SLOG(ZIL – ZFS Intent Log라고도 함)라고 하는 빠른 별도의 캐싱 장치에 쓰기를 통해 비동기식 쓰기로 변환할 수 있습니다.
  • 조정 가능성이 높습니다. 최적의 기능을 위해 많은 내부 파라미터를 구성할 수 있습니다.
  • 이 용도로 완전히 설계되지는 않았지만 고가용성 클러스터 및 컴퓨팅에 사용할 수 있습니다.

데이터 무결성

참고 항목: 하드 디스크 오류율 및 처리 및 사일런트 데이터 손상

ZFS가 다른 파일 시스템과 구별되는 한 가지 주요 특징은 데이터 열화, 전원 서지(전압 스파이크), 디스크 펌웨어의 버그, 팬텀 쓰기(이전 쓰기가 디스크에 도달하지 않음)로 인한 조용한 데이터 손상으로부터 디스크의 사용자 데이터를 보호함으로써 데이터 무결성에 중점을 두고 설계되었다는 점입니다. 잘못된 방향의 읽기/쓰기(디스크가 잘못된 블록에 액세스함), 어레이와 서버 메모리 사이 또는 드라이버의 DMA 패리티 오류(체크섬이 어레이 내부의 데이터를 확인하므로), 드라이버 오류(커널 내부의 잘못된 버퍼에 데이터가 저장됨), 실수로 덮어쓰기(예: 라이브 파일 시스템으로 스왑) 등이 있습니다.

1999년의 한 연구에 따르면 당시 주요하고 널리 사용되던 파일 시스템(UFS, Ext,[21] XFS, JFS, NTFS 등)과 하드웨어 RAID(데이터 무결성에 문제가 있는) 모두 데이터 손상 문제에 대한 충분한 보호 기능을 제공하지 못했습니다.[22][23][24][25] 초기 연구에 따르면 ZFS는 이전의 노력보다 데이터를 더 잘 보호합니다.[26][27] 또한 UFS보다[28][29] 빠르며 대체품으로 볼 수 있습니다.

ZFS 내에서 데이터 무결성은 파일 시스템 트리 전체에 걸쳐 Fletcher 기반 체크섬 또는 SHA-256 해시를 사용하여 달성됩니다.[30] 각 데이터 블록은 체크섬되고 체크섬 값은 실제 블록 자체가 아니라 해당 블록의 포인터에 저장됩니다. 그런 다음 블록 포인터가 체크섬되고 해당 포인터에 값이 저장됩니다. 이 체크섬은 파일 시스템의 데이터 계층에서 루트 노드까지 계속 진행되며, 루트 노드도 체크섬되어 머클 트리가 생성됩니다.[30] 대부분의 파일 시스템은 체크섬을 데이터와 함께 저장하기 때문에 기내 데이터 손상 또는 팬텀 읽기/쓰기(기록된 데이터/읽기 체크섬은 정확하지만 실제로는 올바르지 않음)를 감지할 수 없습니다. ZFS는 각 블록의 체크섬을 상위 블록 포인터에 저장하여 전체 풀이 자체적으로 검증되도록 합니다.[30]

데이터인지 메타 데이터인지에 관계없이 블록에 액세스하면 해당 블록의 체크섬이 계산되고 저장된 체크섬 값과 비교됩니다. 체크섬이 일치하면 데이터는 프로그래밍 스택에서 요청한 프로세스로 전달됩니다. 값이 일치하지 않으면 ZFS는 데이터 복사본이 손상되지 않고 체크섬이 일치한다고 가정할 때 스토리지 풀에서 데이터 중복성(내부 미러링 등)을 제공하면 데이터를 복구할 수 있습니다.[31] 선택적으로 지정하여 풀 내 중복성을 추가로 제공할 수 있습니다. copys=2(또는 copys=3). 즉, 데이터가 디스크에 두 번(또는 세 번) 저장되어 디스크의 저장 용량을 효과적으로 절반(또는 copys=3의 경우 1/3으로 감소)으로 줄여줍니다. 또한 ZFS에서 풀을 관리하는 데 사용하는 일부 데이터는 기본 복사본=1 설정에서도 안전을 위해 기본적으로 여러 번 저장됩니다.

손상된 데이터의 다른 복사본이 존재하거나 체크섬 및 패리티 데이터에서 재구성할 수 있는 경우 ZFS는 데이터 복사본을 사용하고(또는 RAID 복구 메커니즘을 통해 다시 생성) 체크섬을 다시 계산하여 원래 예상 값을 재현하는 것이 이상적입니다. 데이터가 이 무결성 검사를 통과하면 시스템은 결함이 있는 모든 복사본을 정상적인 데이터로 업데이트할 수 있으며 중복성이 복원됩니다.

손상된 데이터의 복사본이 없는 경우 ZFS는 풀을 결함 상태로 [33]만들어 향후 사용을 방지하고 풀 내용을 복구할 수 있는 문서화된 방법을 제공하지 않습니다.

메모리에 보유된 데이터(예: ARC의 캐시된 데이터)의 일관성은 기본적으로 확인되지 않습니다. ZFS는 RAM을 수정하는 오류가 있는 엔터프라이즈급 하드웨어에서 실행될 것으로 예상되기 때문입니다. 그러나 메모리 내 데이터를 확인할 수 있는 기능이 있으며 "디버그 플래그"를 사용하여 활성화할 수 있습니다.[34]

RAID("RAID-Z")

ZFS가 데이터 무결성을 보장하려면 일반적으로 여러 디스크에 분산된 여러 데이터 복사본이 필요합니다. 이는 일반적으로 RAID 컨트롤러 또는 소위 "소프트" RAID(파일 시스템에 내장된)를 사용하여 수행됩니다.

하드웨어 RAID 컨트롤러 회피

ZFS는 하드웨어 RAID 장치와 함께 작동할 수 있지만, 일반적으로 모든 스토리지 장치에 원시적으로 액세스할 수 있는 경우 더 효율적이고 더 큰 데이터 보호 기능을 제공합니다. ZFS는 데이터가 안전하게 기록된 것으로 확인되는 순간을 정확하게 파악하기 위해 디스크에 의존하며 캐싱, 캐시 플러싱 및 디스크 처리를 최적화하도록 설계된 수많은 알고리즘을 갖추고 있습니다.

하드웨어, 펌웨어, 기타 "소프트" RAID 또는 ZFS-디스크 I/O 경로를 수정하는 기타 컨트롤러를 사용하여 시스템에 연결된 디스크는 ZFS 성능 및 데이터 무결성에 영향을 미칩니다. 타사 장치가 캐싱을 수행하거나 ZFS에 드라이브를 하나의 시스템으로 제공하는 경우 ZFS가 의존하는 낮은 레벨 뷰 없이 시스템의 성능이 저하되고 ZFS가 장애를 방지하거나 장애를 복구하는 속도가 느려지거나 쓰기 장애로 인해 데이터가 손실될 가능성이 훨씬 더 높아집니다. 예를 들어, 하드웨어 RAID 카드를 사용하는 경우, ZFS는 디스크의 상태를 파악하지 못하거나, RAID 어레이의 성능 저하 또는 재구축 여부를 확인하거나, 모든 데이터 손상을 감지하거나, 디스크 전체에 데이터를 최적으로 배치하거나, 선택적 수리를 수행하거나, 수리가 지속적인 사용과 균형을 맞추는 방법을 제어하거나, ZFS가 일반적으로 수행할 수 있는 수리를 수행하지 못할 수 있습니다. 하드웨어 RAID 카드는 ZFS의 알고리즘을 방해합니다. 또한 RAID 컨트롤러는 일반적으로 컨트롤러에 의존하는 데이터를 드라이브에 추가하므로 소프트웨어 RAID가 사용자 데이터에 액세스할 수 없습니다. 하드웨어 RAID 컨트롤러에 장애가 발생한 경우 다른 호환 컨트롤러로 데이터를 읽을 수도 있지만 항상 이 문제가 발생할 수는 없으며 교체가 불가능할 수도 있습니다. 대체 하드웨어 RAID 컨트롤러는 어레이를 관리하고 복원하는 데 필요한 원래 제조업체의 사용자 지정 데이터를 이해하지 못할 수 있습니다.

RAID 카드 또는 이와 유사한 하드웨어가 리소스 및 처리를 오프로드하여 성능과 신뢰성을 향상시킬 수 있는 대부분의 다른 시스템과 달리 ZFS의 경우 이러한 방법은 일반적으로 시스템의 성능과 신뢰성을 저하시키므로 사용하지 않는 것이 좋습니다.

RAID 또는 다른 컨트롤러를 통해 디스크를 연결해야 하는 경우 일반 HBA(호스트 어댑터), 간단한 팬아웃 카드를 사용하거나 JBOD 모드로 카드를 구성(예: RAID 및 캐싱 기능 해제)하여 컨트롤러에서 처리되는 양을 최소화하는 것이 좋습니다. ZFS-Disk I/O 경로를 최소한으로 변경하여 장치를 연결할 수 있도록 합니다. JBOD 모드의 RAID 카드는 캐시가 있는 경우에도 방해가 되거나 설계에 따라 드라이브가 제때 응답하지 않는 드라이브를 분리할 수 있습니다(에너지 효율이 높은 소비자용 하드 드라이브에서 볼 수 있듯이). 따라서 드라이브 드롭을 방지하기 위해 TLER(Time-Limited Error Recovery)/CCTL/ERC 지원 드라이브가 필요할 수 있습니다. 따라서 RAID 기능이 비활성화된 상태에서도 모든 카드가 적합한 것은 아닙니다.[35]

ZFS의 접근 방식: RAID-Z 및 미러링

ZFS는 하드웨어 RAID 대신 "소프트" RAID를 사용하여 RAID-Z(RAID 5 등 패리티 기반)와 디스크 미러링(RAID 1과 유사)을 제공합니다. 계획은 매우 유연합니다.

RAID-Z는 RAID-5와 같은 데이터/패리티 배포 방식이지만 동적 스트라이프 폭을 사용합니다. 블록 크기에 상관없이 모든 블록은 자체 RAID 스트라이프이므로 모든 RAID-Z 쓰기는 전체 스트라이프 쓰기가 됩니다. 이것은 ZFS의 복사-온-쓰기 트랜잭션 시맨틱스와 결합되면 쓰기 홀 오류를 제거합니다. RAID-Z는 또한 일반적인 읽기-수정-쓰기 시퀀스를 수행할 필요가 없기 때문에 기존 RAID 5보다 빠릅니다.[36]

모든 스트라이프의 크기가 다르기 때문에 RAID-Z 재구성은 실제 RAID-Z 지오메트리를 확인하기 위해 파일 시스템 메타데이터를 통과해야 합니다. 파일 시스템과 RAID 어레이가 별개의 제품일 경우에는 불가능하지만 데이터의 논리적 및 물리적 구조를 통합적으로 볼 수 있는 경우에는 가능합니다. 메타데이터를 검토한다는 것은 ZFS가 256비트 체크섬을 기준으로 모든 블록을 검증할 수 있다는 것을 의미하지만, 기존 RAID 제품은 일반적으로 이를 검증할 수 없습니다.[36]

RAID-Z는 전체 디스크 장애를 처리하는 것 외에도 "자기 복구 데이터"를 제공하여 "자기 복구 데이터"를 감지하고 수정할 수 있습니다. RAID-Z 블록을 읽을 때 ZFS가 체크섬과 비교하고 데이터 디스크가 정답을 반환하지 않으면 ZFS가 패리티를 읽고 불량 데이터를 반환한 디스크를 계산합니다. 그런 다음 손상된 데이터를 복구하고 요청자에게 좋은 데이터를 반환합니다.[36]

RAID-Z 및 미러링은 특별한 하드웨어가 필요하지 않습니다. 신뢰성을 위해 NVRAM이 필요하지 않으며, 우수한 성능이나 데이터 보호를 위해 쓰기 버퍼링이 필요하지 않습니다. RAID-Z를 사용하는 ZFS는 저렴한 상품 디스크를 사용하여 빠르고 안정적인 스토리지를 제공합니다.[promotion?][36]

스트라이핑(RAID 0과 유사, 중복성 제공 없음), RAID-Z1(RAID 5와 유사, 디스크 1개 장애 허용), RAID-Z2(RAID 6과 유사, 디스크 2개 장애 허용), RAID-Z3(RAID 7 구성[a], 디스크 3개 장애 허용), 미러링(RAID 1과 유사, 디스크 1개를 제외한 모든 장애 허용)[38]의 5가지 다른 RAID-Z 모드가 있습니다.

RAID-Z3의 필요성은 2000년대 초반에 멀티 테라바이트 용량의 드라이브가 보편화되면서 대두되었습니다. 이와 같은 용량 증가는 처리 속도의 증가 없이 드라이브 장애로 인해 어레이를 재구축하는 데 "몇 주 또는 몇 달"이 걸릴 수 있음을 의미합니다.[37] 이 기간 동안 어레이의 오래된 디스크는 추가 작업량으로 인해 스트레스를 받게 되며, 이로 인해 데이터가 손상되거나 드라이브에 장애가 발생할 수 있습니다. RAID-Z3는 패리티를 증가시킴으로써 단순히 중복성을 증가시킴으로써 데이터 손실 가능성을 줄입니다.[39]

복원 및 스크럽(어레이 동기화 및 무결성 검사)

ZFS에는 fsck(파일 시스템용 표준 유닉스 및 리눅스 데이터 검사 및 복구 도구)와 동등한 도구가 없습니다.[40] 대신 ZFS에는 정기적으로 모든 데이터를 검사하고 조용한 손상 및 기타 문제를 복구하는 스크럽 기능이 내장되어 있습니다. 몇 가지 차이점은 다음과 같습니다.

  • fsck는 오프라인 파일 시스템에서 실행되어야 합니다. 즉, 파일 시스템은 마운트 해제되어야 하며 복구되는 동안에는 사용할 수 없습니다. 반면 스크럽은 마운트된 라이브 파일 시스템에서 사용하도록 설계되었으며 ZFS 파일 시스템을 오프라인으로 전환할 필요가 없습니다.
  • fsck는 보통 메타데이터(예: 저널 로그)만 확인할 뿐 데이터 자체는 확인하지 않습니다. 즉, fsck 후에도 데이터가 저장된 원래 데이터와 일치하지 않을 수 있습니다.
  • fsck는 체크섬이 데이터와 함께 저장될 때 항상 데이터의 유효성을 검사하고 복구할 수는 없습니다. 체크섬이 손상되거나 읽을 수 없기 때문입니다. ZFS는 항상 확인하는 데이터와 별도로 체크섬을 저장하므로 신뢰성과 스크럽을 통해 볼륨을 복구할 수 있습니다. 또한 ZFS는 여러 개의 데이터 복사본을 저장합니다. 특히 메타데이터의 경우 최대 4~6개의 복사본(디스크당 여러 개의 복사본과 볼륨당 여러 개의 디스크 미러)을 가질 수 있으므로 fsck에 비해 볼륨의 광범위한 손상을 감지하고 복구하는 스크럽 기능이 크게 향상됩니다.
  • 스크럽은 메타데이터와 데이터를 포함한 모든 것을 확인합니다. fsck와 스크럽 시간을 비교하면 효과를 확인할 수 있습니다. 대규모 RAID에 대한 fsck는 몇 분 만에 완료되므로 메타데이터만 확인할 수 있습니다. 대규모 RAID에서 모든 메타데이터와 데이터를 탐색하는 데는 수 시간이 소요되며, 이는 스크럽이 수행하는 작업과 정확히 일치합니다.
  • fsck는 사용 가능한 파일 시스템 데이터를 사용하여 오류를 감지하고 수정하려고 하지만 스크럽은 문제를 복구하기 위해 이중화에 의존합니다. fsck는 부분적인 데이터 손실로 파일 시스템을 수정할 수 있지만, 스크럽은 중복성이 없을 경우 파일 시스템을 결함 상태로 만듭니다.[33]

Sun/Oracle의 공식 권장 사항은 엔터프라이즈급 디스크는 한 달에 한 번 스크럽하고, 일반 디스크는 일주일에 한 번 더 저렴한 가격으로 스크럽하는 것입니다.[41][42]

용량.

ZFS는 128비트 파일 시스템이므로 [43][15]Btrfs와 같은 64비트 시스템보다 1.84 × 10배19 많은 데이터를 처리할 수 있습니다. ZFS의 최대 한계는 실제로는 결코 마주칠 수 없을 정도로 크게 설계되었습니다. 예를 들어, 하나의 zpool에 2비트의128 데이터를 완전히 채우려면 3×10TB의24 하드 디스크 드라이브가 필요합니다.[44]

ZFS의 몇 가지 이론적 한계는 다음과 같습니다.

  • 16 엑비바이트(2바이트64): 단일 파일의 최대 크기
  • 248: 임의의 개별 디렉토리에[45] 있는 항목 수
  • 16 엑비바이트: 모든 속성의 최대 크기
  • 2: 파일의 속성 수(디렉토리의 파일 수는 2로 제한된 actually)
  • 256128,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000
  • 264: zpool 내 장치 수
  • 264: zpool 내 파일 시스템 수
  • 264: 시스템 내 zpool 수

암호화

Oracle Solaris를 사용하면 ZFS의[46] 암호화 기능이 I/O 파이프라인에 내장됩니다. 쓰기 중에는 블록을 압축, 암호화, 체크섬한 후 중복 제거할 수 있습니다. 암호화 정책은 데이터셋(파일 시스템 또는 ZVOL)이 생성될 때 데이터셋 수준에서 설정됩니다. 사용자/관리자가 제공하는 래핑 키는 파일 시스템을 오프라인으로 전환하지 않고도 언제든지 변경할 수 있습니다. 기본 동작은 래핑 키가 하위 데이터 세트에서 상속되는 것입니다. 데이터 암호화 키는 데이터 세트 생성 시 무작위로 생성됩니다. 하위 데이터셋(스냅샷 및 클론)만 데이터 암호화 키를 공유합니다.[47] 클론의 새 데이터 암호화 키로 전환하거나 언제든지 암호화된 마스터 키 메커니즘을 사용하여 기존 데이터를 재암호화하지 않는 명령이 제공됩니다.

2019년 현재 암호화 기능은 데비안 및 우분투 리눅스 배포판에서 사용할 수 있는 OpenZFS 0.8.0에도 완전히 통합되어 있습니다.[48]

읽기/쓰기 효율성

ZFS는 일반적으로 풀의 성능을 최대화하는 방식으로 풀의 모든 vdev(및 각 vdev의 모든 장치)에 데이터 스토리지를 자동으로 할당합니다. 또한 ZFS는 풀에 추가된 새 디스크를 고려하여 쓰기 전략을 업데이트합니다.

일반적으로 ZFS는 각 vdev의 사용 가능한 공간을 기준으로 vdev 전반에 걸쳐 쓰기를 할당합니다. 이를 통해 이미 데이터가 비례적으로 적은 vdev에 새 데이터를 저장할 때 더 많은 쓰기가 제공됩니다. 이를 통해 풀의 사용이 증가함에 따라 일부 vdev가 가득 차게 되어 제한된 수의 디바이스에서 쓰기가 수행되는 상황이 발생하지 않도록 할 수 있습니다. 또한 데이터를 읽을 때(그리고 대부분의 경우에는 쓰기보다 읽기가 훨씬 더 빈번합니다) 데이터의 서로 다른 부분을 가능한 한 많은 디스크에서 동시에 읽을 수 있어 훨씬 더 높은 읽기 성능을 제공합니다. 따라서 일반적으로 풀과 vdev를 관리하고 새 스토리지를 추가해야 하므로 풀의 일부 vdev는 거의 가득 차 있고 다른 vdev는 거의 비어 있는 상황이 발생하지 않습니다. 그러면 풀의 효율성이 저하됩니다.

기타특징

스토리지 디바이스, 스페어 및 할당량

풀에는 장애가 발생한 디스크를 보상하기 위해 핫 스페어가 있을 수 있습니다. 미러링 시 물리적 섀시에 따라 블록 장치를 그룹화할 수 있으므로 전체 섀시에 장애가 발생할 경우 파일 시스템을 계속 유지할 수 있습니다.

스토리지 풀 구성은 유사한 장치에 국한되지 않고 임의의 이기종 장치 모음으로 구성될 수 있으며 ZFS는 이러한 장치를 원활하게 풀링하여 필요에 따라 데이터셋(파일 시스템 인스턴스 또는 ZVOL)에 공간을 할당합니다. 임의의 저장 장치 유형을 기존 풀에 추가하여 크기를 확장할 수 있습니다.[49]

모든 vdev의 스토리지 용량은 zpool의 모든 파일 시스템 인스턴스에서 사용할 수 있습니다. 파일 시스템 인스턴스가 차지할 수 있는 공간을 제한하기 위해 할당량을 설정할 수 있으며, 파일 시스템 인스턴스가 사용할 수 있는 공간을 보장하기 위해 예약을 설정할 수 있습니다.

캐싱 메커니즘: ARC, L2ARC, 트랜잭션 그룹, ZIL, SLOG, Special VDEV

ZFS는 다양한 계층의 디스크 캐시를 사용하여 읽기 및 쓰기 작업 속도를 높입니다. 이상적으로는 모든 데이터를 RAM에 저장해야 하지만 일반적으로 너무 비쌉니다. 따라서 비용 대비 성능을 최적화하기 위해 데이터가 계층에 자동으로 캐싱됩니다.[50] 이러한 데이터를 종종 "하이브리드 스토리지 풀"이라고 부릅니다.[51] 자주 액세스하는 데이터는 RAM에 저장되며, 덜 자주 액세스하는 데이터는 솔리드 스테이트 드라이브(SSD)와 같은 느린 미디어에 저장될 수 있습니다. 자주 액세스하지 않는 데이터는 캐시되지 않고 느린 하드 드라이브에 남겨집니다. 오래된 데이터가 갑자기 많이 읽히면 ZFS가 자동으로 SSD나 RAM으로 이동합니다.

ZFS 캐싱 메커니즘은 읽기와 쓰기에 각각 하나씩 포함되며, 각 경우에 두 가지 수준의 캐싱이 존재할 수 있습니다. 하나는 RAM(컴퓨터 메모리)에 있고 하나는 SSD(일반적으로 솔리드 스테이트 드라이브)에 있으며, 하나는 총 4개의 캐싱에 사용됩니다.

보관장소 캐시 읽기 쓰기 캐시
일급캐시 RAM에서 ARC(adaptive replacement cache) 알고리즘의 변형을 사용하기 때문에 ARC로 알려져 있습니다. RAM은 항상 캐싱에 사용되므로 이 수준은 항상 존재합니다. ARC 알고리즘의 효율성은 ARC 크기가 충분히 클 경우 디스크에 액세스할 필요가 없는 경우가 많다는 것을 의미합니다. RAM이 너무 작으면 ARC가 거의 발생하지 않습니다. 이 경우 ZFS는 항상 기본 Disk에 액세스해야 하므로 성능에 상당한 영향을 미칩니다. "거래 그룹"을 통해 처리 – 쓰기는 주어진 제한 시간까지 짧은 기간(일반적으로 5~30초)에 걸쳐 대조되며, 각 그룹은 다음 그룹이 대조되는 동안 이상적으로 디스크에 기록됩니다. 이를 통해 전원 중단이나 하드웨어 장애 시 가장 최근 트랜잭션의 데이터가 약간 손실될 위험이 있는 기본 Disk에 대해 쓰기를 보다 효율적으로 구성할 수 있습니다. 실제로 전력 손실 위험은 ZFS 쓰기 저널링과 SLOG/ZIL 2계층 쓰기 캐시 풀(아래 참조)에 의해 방지되므로 쓰기 실패가 2계층 SLOG 풀의 전체 손실과 동시에 발생하는 경우에만 쓰기가 손실됩니다. 그런 다음 동기식 쓰기 및 SLOG 사용과 관련된 설정이 그러한 상황이 발생할 수 있도록 설정될 때만 가능합니다. 데이터가 기록할 수 있는 속도보다 빠르게 수신되면 디스크가 따라잡을 때까지 데이터 수신이 일시 중지됩니다.
2단계 캐시 & 인텐트 로그 고속 스토리지 장치(기존 버전의 ZFS에서는 중단 없이 "라이브" 시스템에서 추가 또는 제거 가능) L2ARC("레벨 2 ARC")로 알려져 있으며, 옵션입니다. ZFS는 L2ARC에서 가능한 한 많은 데이터를 캐싱할 것이며, 이는 많은 경우 수십 기가바이트 또는 수백 기가바이트가 될 수 있습니다. 전체 중복제거 테이블을 L2ARC에 캐싱할 수 있다면 L2ARC는 중복제거 속도도 상당히 빨라질 것입니다. L2ARC를 빈 상태에서 완전히 채우는 데는 몇 시간이 걸릴 수 있습니다(ZFS가 "핫"하고 캐시해야 할 데이터를 결정하기 전까지). L2ARC 장치가 손실되면 모든 읽기가 디스크로 나가 성능이 저하되지만 그 외에는 아무 일도 일어나지 않습니다(데이터가 손실되지 않습니다). SLOG 또는 ZIL("ZFS Intent Log")로 알려진 용어는 종종 잘못 사용됩니다. SLOG(세컨더리 로그 장치)는 시스템 문제가 발생할 경우 쓰기를 기록하기 위해 별도의 장치에 있는 선택적인 전용 캐시입니다. SLOG 장치가 존재할 경우 ZFS Intent Log에 두 번째 레벨 로그로 사용되며, 별도의 캐시 장치가 제공되지 않을 경우 주 저장 장치에 대신 ZIL이 생성됩니다. 따라서, 엄밀히 말해, SLOG는 풀의 속도를 높이기 위해 ZIL이 오프로드되는 전용 디스크를 말합니다. 엄밀히 말하면 ZFS는 SLOG 장치를 사용하여 디스크 쓰기를 캐시하지 않습니다. 대신, 쓰기를 최대한 빨리 영구 저장 매체에 캡처하여 전력 손실이나 쓰기 실패 시 쓰기로 인식된 데이터가 손실되지 않도록 하기 위해 SLOG를 사용합니다. SLOG 장치를 사용하면 훨씬 느린 HDD와 같은 스토리지 장치에서도 ZFS가 쓰기를 빠르게 저장하고 쓰기대로 빠르게 보고할 수 있습니다. 일반적인 활동 과정에서, SLOG는 참조되거나 읽혀지지 않으며 캐시 역할을 하지 않습니다. SLOG의 목적은 최종 쓰기가 실패할 경우를 대비하여 대조 및 "쓰기"에 소요되는 몇 초 동안 이동 중인 데이터를 보호하는 것입니다. 모든 작업이 잘 진행되면 스토리지 풀이 다음 5~60초 이내에 업데이트됩니다. 이때 현재 트랜잭션 그룹이 디스크에 기록됩니다(위 참조). 이 시점에서 저장된 SLOG의 쓰기는 단순히 무시되고 덮어씁니다. 쓰기가 실패하거나 시스템에 충돌이나 오류가 발생하여 쓰기가 불가능한 경우 ZFS는 쓰기가 확인된 모든 쓰기를 식별하고, 이를 통해 데이터 손실을 완전히 복구할 수 있습니다.

이 문제는 클라이언트가 활동을 계속하기 전에 성공적인 쓰기를 확인해야 [52]하는 경우(예: ESXi, NFS 및 일부 데이터베이스)에 대한 동기식 쓰기가 대량으로 수행되는 경우) 매우 중요합니다. SLOG를 통해 ZFS는 매번 메인 저장소에 쓰기를 수행해야 하는 경우보다 훨씬 더 빠르게 쓰기가 성공적인지 확인할 수 있습니다. 데이터 저장 상태에 대해 고객을 오도하는 위험 없이. SLOG 장치가 없는 경우 메인 데이터 풀의 일부가 더 느리지만 동일한 용도로 사용됩니다.

로그 장치 자체가 손실되면 최신 쓰기가 손실될 수 있으므로 로그 장치를 미러링해야 합니다. 이전 버전의 ZFS에서는 로그 장치가 손실되면 전체 zpool이 손실될 수 있지만, 더 이상 그렇지 않습니다. 따라서 별도의 로그 장치를 사용할 계획이라면 ZFS를 업그레이드해야 합니다.

ZFS 내에는 수많은 다른 캐시, 캐시 분할 및 큐도 존재합니다. 예를 들어, 각 VDEV에는 자체 데이터 캐시가 있으며, ARC 캐시는 사용자가 저장한 데이터와 ZFS가 사용하는 메타데이터로 구분되며, 이들 간의 균형을 제어합니다.

특수 VDEV 클래스

OpenZFS 0.8 이상에서는 파일 시스템 메타데이터와 DDT(Data Deduplication Table) 및 작은 파일 시스템 블록을 우선적으로 저장하도록 Special VDEV 클래스를 구성할 수 있습니다.[53] 예를 들어 고속 솔리드 스테이트 스토리지에 특수 VDEV를 생성하여 메타데이터를 저장하고 일반 파일 데이터는 회전 디스크에 저장할 수 있습니다. 이를 통해 전체 파일 시스템을 솔리드 스테이트 스토리지에 저장하는 비용 없이 파일 시스템 순회, 스크럽 및 복원력과 같은 메타데이터 집약적인 작업 속도를 높일 수 있습니다.

Copy-on-write 트랜잭션 모델

ZFS는 복사-온-라이트 트랜잭션 개체 모델을 사용합니다. 파일 시스템 내의 모든 블록 포인터는 대상 블록의 256비트 체크섬 또는 256비트 해시([54]현재 Fletcher-2, Fletcher-4 또는 SHA-256 중 하나)를 포함하며, 이는 블록을 읽을 때 확인됩니다. 활성 데이터가 포함된 블록은 제자리에서 덮어쓰지 않으며, 대신 새 블록을 할당하고 수정된 데이터를 작성한 다음 이를 참조하는 메타데이터 블록도 마찬가지로 읽고 재할당하고 작성합니다. 이 프로세스의 오버헤드를 줄이기 위해 여러 업데이트를 트랜잭션 그룹으로 그룹화하고 동기식 쓰기 시맨틱스가 필요한 경우 ZIL(intent log) 쓰기 캐시를 사용합니다. 블록은 트리에 배열되며 체크섬도 마찬가지입니다(Merkle signature scheme 참조).

스냅샷 및 클론

Copy-on-write의 장점은 ZFS가 새 데이터를 쓸 때 이전 데이터를 포함하는 블록을 유지할 수 있기 때문에 파일 시스템의 스냅샷 버전을 유지할 수 있다는 것입니다. ZFS 스냅샷은 일관적이며(한 시점에 존재했던 전체 데이터를 반영합니다), 스냅샷을 구성하는 모든 데이터가 이미 저장되어 있기 때문에 전체 스토리지 풀이 시간당 여러 번 스냅샷되는 경우가 많기 때문에 매우 빠르게 생성할 수 있습니다. 또한 변경되지 않은 데이터는 파일 시스템과 해당 스냅샷 간에 공유되므로 공간 효율적입니다. 스냅샷은 기본적으로 읽기 전용이므로 생성 후에도 수정되지 않습니다. 단, 백업 수단으로만 사용해서는 안 됩니다. 전체 스냅샷을 복원할 수 있으며 스냅샷 내의 파일 및 디렉토리도 복원할 수 있습니다.

쓰기 가능한 스냅샷("Clone")도 생성할 수 있으므로 블록 집합을 공유하는 두 개의 독립적인 파일 시스템이 생성됩니다. 클론 파일 시스템이 변경되면 이러한 변경 사항을 반영하기 위해 새로운 데이터 블록이 생성되지만, 변경되지 않은 블록은 클론 수에 관계없이 계속 공유됩니다. 이것은 Copy-on-write 원칙을 구현한 것입니다.

스냅샷 송수신

send 명령을 사용하면 파일 시스템의 상태에 대한 스트림 표현이 생성되므로 ZFS 파일 시스템을 네트워크를 통해 원격 호스트의 다른 풀로 이동할 수 있습니다. 이 스트림은 지정된 스냅샷에서 파일 시스템의 전체 내용을 설명하거나 스냅샷 간의 델타(delta)일 수 있습니다. 델타 스트림을 계산하는 것은 매우 효율적이며, 델타 스트림의 크기는 스냅샷 간에 변경되는 블록 수에 따라 달라집니다. 이를 통해 풀의 오프사이트 백업이나 고가용성 미러를 동기화하는 등 효율적인 전략을 제공할 수 있습니다.

동적 스트리핑

처리량을 극대화하기 위해 모든 장치에 동적으로 스트라이프를 적용한다는 것은 zpool에 추가된 장치가 있으면 스트라이프 폭이 자동으로 확장되어 zpool에 포함되므로 풀에 있는 모든 디스크가 사용되므로 전체적으로 쓰기 부하가 균형을 이룬다는 것을 의미합니다.[55]

블록 크기 가변

ZFS는 가변 크기의 블록을 사용하며 기본 크기는 128KB입니다. 사용 가능한 기능을 사용하면 관리자가 사용할 수 있는 최대 블록 크기를 조정할 수 있습니다. 특정 워크로드가 큰 블록에서는 제대로 수행되지 않기 때문입니다. 데이터 압축이 활성화된 경우 가변 블록 크기가 사용됩니다. 블록을 더 작은 블록 크기에 맞게 압축할 수 있는 경우, 디스크에서 더 작은 크기를 사용하여 스토리지 사용량을 줄이고 IO 처리량을 향상시킵니다(압축 및 압축 해제 작업에 대한 CPU 사용 증가의 대가를 치르더라도).[56]

경량 파일 시스템 생성

ZFS에서는 스토리지 풀 내의 파일 시스템 조작이 기존 파일 시스템 내의 볼륨 조작보다 더 쉽습니다. ZFS 파일 시스템을 만들거나 확장하는 데 필요한 시간과 노력은 다른 일부 시스템의 볼륨 조작보다 새 디렉터리를 만드는 데 더 가깝습니다.[citation needed]

적응적 엔디안니스

풀 및 관련 ZFS 파일 시스템은 서로 다른 바이트 순서를 구현하는 시스템을 포함하여 서로 다른 플랫폼 아키텍처 간에 이동할 수 있습니다. ZFS 블록 포인터 형식은 파일 시스템 메타데이터를 엔디안 적응 방식으로 저장합니다. 개별 메타데이터 블록은 블록을 작성하는 시스템의 네이티브 바이트 순서로 작성됩니다. 판독 시 저장된 엔디안이 시스템의 엔디안과 일치하지 않으면 메타데이터가 메모리에 바이트 스왑됩니다.

이것은 저장된 데이터에 영향을 미치지 않습니다. POSIX 시스템의 일반적인 경우와 마찬가지로 파일은 단순한 바이트 배열로 애플리케이션에 표시되므로 데이터를 생성하고 읽는 애플리케이션은 기본 시스템의 독립성과 무관한 방식으로 데이터를 생성할 책임이 있습니다.

중복제거

데이터 중복 제거 기능은 2009년 10월 말에 ZFS 소스 저장소에 추가되었으며,[57] 관련 OpenSolaris ZFS 개발 패키지는 2009년 12월 3일(빌드 128)부터 제공되고 있습니다.

중복제거를 효과적으로 사용하려면 대용량의 RAM이 필요할 수 있습니다. 스토리지 1TB당 1GB에서 5GB의 RAM이 권장됩니다.[58][59][60] 중복제거에 필요한 메모리의 정확한 평가는 풀의 고유 블록 수와 각 레코드를 저장하는 데 필요한 디스크 및 RAM("core")의 바이트 수를 참조하여 이루어집니다. zpool 그리고. zdb. 물리적 메모리가 부족하거나 ZFS 캐시가 부족하면 중복제거를 사용할 때 가상 메모리가 손상되어 성능이 저하되거나 메모리가 완전히 부족해질 수 있습니다.[citation needed] 중복제거는 쓰기 시간에 발생하기 때문에 CPU를 많이 사용하기 때문에 시스템 속도를 크게 저하시킬 수도 있습니다.

다른 스토리지 벤더들은 매우 높은 데이터 압축률을 달성하기 위해 ZFS의 수정된 버전을 사용합니다. 2012년의 두 가지 예는[61] GreenBytes와 Tegile이었습니다.[62] 2014년 5월, 오라클은 ZFS 중복제거 및 복제 기술을 위해 GreenBytes를 인수했습니다.[63]

앞서 설명한 바와 같이 중복제거는 시스템 및 데이터가 이러한 공간 절약 기술에 적합한 특정 환경을 제외하고는 리소스 요구사항(특히 RAM)이 과도하고 성능에 미치는 영향(특히 쓰기 시) 때문에 권장되지 않습니다.

추가 기능

  • 기한 스케줄링을 통한 명시적 I/O 우선순위.[citation needed]
  • 전 세계적으로 최적의 I/O 정렬 및 집계를 요구합니다.[citation needed]
  • 자동 길이 및 스트라이드 감지 기능이 있는 여러 개의 독립적인 프리페치 스트림입니다.[citation needed]
  • 병렬, 상시 디렉토리 작업입니다.[citation needed]
  • 일종의 "Data Integrity Field(데이터 무결성 필드)"를 사용하는 엔드 투 엔드 체크섬 방식으로 데이터 손상 탐지(및 풀에 중복성이 있는 경우 복구)가 가능합니다. 속도(플렛처), 표준화 및 보안(SHA256), 솔티드 해쉬(스케인)에 최적화된 3가지 해쉬를 선택하여 사용할 수 있습니다.[64]
  • 투명한 파일 시스템 압축. Supports LZJB, gzip,[65] LZ4 and Zstd.
  • 지능형 스크러빙 및 복원력(재합성)이 있습니다.[66]
  • 풀의 디스크 간 로드 및 공간 사용량 공유.[67]
  • Ditto blocks: 파일 시스템별로 구성 가능한 데이터 복제로, 사용자 데이터에 대해 쓰기당 1개 또는 2개의 추가 복사본을 요청하고, 기본 복사본 수가 동일하고 메타데이터에 대해 1개 또는 2개를 추가합니다(메타데이터 중요도에 따라).[68] 풀에 여러 장치가 있는 경우 ZFS는 여러 장치에 걸쳐 복제를 시도합니다. Ditto 블록은 주로 손상된 섹터에 대한 추가적인 보호 기능이며, 전체 Disk 장애에 대한 보호 기능은 아닙니다.[69]
  • ZFS 설계(Copy-on-write + superblocks)는 쓰기 캐시가 활성화된 디스크를 사용할 때 쓰기 장벽을 지킬 경우 안전합니다.[citation needed] 이 기능은 다른 일부 파일 시스템에 비해 안전성과 성능을 향상시킵니다.[according to whom?]
  • Solaris에서는 전체 디스크가 ZFS 풀에 추가되면 ZFS가 자동으로 쓰기 캐시를 활성화합니다. ZFS가 디스크의 개별 슬라이스만 관리하는 경우에는 다른 슬라이스가 UFS와 같이 쓰기 캐시가 아닌 안전한 파일 시스템에 의해 관리되는지 여부를 알지 못하기 때문에 이러한 작업은 수행되지 않습니다.[citation needed] 더 프리비SD 구현은 GEOM 프레임워크 덕분에 파티션에 대한 디스크 플러시를 처리할 수 있으므로 이러한 제한을 받지 않습니다.[citation needed]
  • 사용자별, 그룹별, 프로젝트별 및 데이터 세트별 할당량 제한.[70]
  • Solaris 11 Express [71]및 OpenZFS(ZoL) 0.8 [53]이후의 파일 시스템 암호화(일부 다른 시스템에서는 ZFS가 비슷한 효과를 위해 암호화된 디스크를 사용할 수 있음, FreeB에서는 GELISD를 사용하여 완전 암호화된 ZFS 스토리지를 생성할 수 있습니다.
  • 풀은 읽기 전용 모드로 가져올 수 있습니다.
  • zpool을 가져올 때 전체 트랜잭션을 롤백하여 데이터를 복구할 수 있습니다.[citation needed]
  • ZFS는 클러스터링된 파일 시스템이 아니지만 타사에서 클러스터링된 ZFS를 사용할 수 있습니다.[citation needed]
  • 스냅샷은 수동 또는 자동으로 촬영할 수 있습니다. 저장된 데이터의 이전 버전은 전체 읽기 전용 파일 시스템으로 노출될 수 있습니다. 또한 CIFS(SMB, 삼바 또는 파일 공유라고도 함)와 함께 사용할 경우 파일과 폴더의 역사적인 버전으로 노출될 수 있습니다. 이 버전은 Windows(윈도우)의 경우 "이전 버전", "VSS 섀도 복사본" 또는 "파일 히스토리" 또는 Apple 장치의 경우 AFP 및 "Apple Time Machine"으로 알려져 있습니다.[72]
  • 디스크는 '예비'로 표시할 수 있습니다. 데이터 풀은 예비 디스크를 활성화하고 필요할 때 의심되는 디스크에 있던 데이터를 복구하여 디스크 장애를 자동으로 투명하게 처리하도록 설정할 수 있습니다.

한계

데이터 손상 방지의 한계

데이터 손상을 감지하고 방지하는 파일 시스템의 기능을 조사한 2010년 연구의 저자. 연구의 저자들은 특히 ZFS에 초점을 두었는데, ZFS가 스토리지 장치의 데이터 오류를 감지하고 수정하도록 설계된 몇 안 되는 파일 시스템 중 하나라는 것을 저자들이 관찰했기 때문입니다. 그럼에도 불구하고 ZFS는 기존의 대부분의 파일 시스템과 마찬가지로 RAM의 데이터가 "안전"하며 오류가 발생하기 쉬운 것은 아니라고 가정합니다. 이 연구는 "메모리의 단일 비트 플립은 작지만 무시할 수 없는 비율의 실행이 실패를 경험하게 하며, 디스크에 불량 데이터를 커밋할 확률은 0%에서 3.6%까지 다양하다"며, ZFS가 페이지를 캐시하거나 메타데이터 복사본을 RAM에 저장할 때, 또는 디스크에 쓰기 위해 데이터를 "dirty" 캐시에 저장합니다. 체크섬이 사용 시점의 데이터와 여전히 일치하는지 여부는 테스트되지 않습니다. 모든 파일 시스템에 존재하며 ZFS를 사용하면 크게 감소하는 데이터 손실 위험을 다음 두 가지 방법 중 하나로 더욱 완화할 수 있습니다.

  • 저자들에 따르면, ECC RAM을 사용함으로써, 그러나 저자들은 페이지 캐시 및 힙과 관련된 오류 탐지를 추가하면 ZFS가 특정 클래스의 오류를 더 강력하게 처리할 수 있다고 생각했습니다.[27]
  • ZFS의 주요 설계자 중 한 명인 Matt Ahrens는 이러한 문제를 해결하는 ZFS_DEBUG_MODIFY 플래그(zfs_flags=0x10)를 사용하여 메모리의 데이터 체크섬을 활성화하는 옵션이 있다고 설명합니다.

ZFS에 특정한 기타 제한 사항

  • 용량 확장은 일반적으로 단순 장치, RAID-Z, RAID Z2, RAID Z3 또는 미러링과 같은 디스크 그룹을 최상위 vdev로 추가하여 이루어집니다. 새로 작성된 데이터는 사용 가능한 모든 vdev를 동적으로 사용하기 시작합니다. 또한 어레이의 각 드라이브를 더 큰 드라이브로 반복적으로 스왑하고 ZFS가 자가 치유되기를 기다리는 방식으로 어레이를 확장할 수도 있습니다. 복구 시간은 디스크 크기가 아닌 저장된 정보의 양에 따라 달라집니다.
  • Solaris 10 Update 11 및 Solaris 11.2에서는 핫 스페어, 캐시 및 로그 디바이스를 제외한 풀의 최상위 vdev 수를 줄이거나 풀 용량을 줄일 수 없었습니다.[74] 이 기능은 2007년에 개발 중이라고 합니다.[75] OpenZFS에서는 vdev를 줄일 수 있는 향상된 기능이 개발 중입니다.[76] 2018년[77] 8월 Solaris 11.4, 2019년 5월 OpenZFS(ZoL) 0.8부터 비중복 최상위 vdev를 제거하여 온라인 축소를 지원합니다.[53]
  • 2008년 현재에는 RAID Z, RAID Z2 또는 RAID Z3 vdev에 디스크를 열로 추가할 수 없었습니다. 대신 새로운 RAID Z vdev를 생성하여 zpool에 추가할 수 있습니다.[78]
  • RAID 51(RAID 5 그룹의 미러)과 같은 일부 기존 중첩 RAID 구성은 일부 타사 도구 없이 ZFS에서 구성할 수 없습니다.[79] Vdevs는 기본 ZFS 관리 명령을 사용하여 다른 Vdevs가 아닌 원시 디스크 또는 파일로만 구성할 수 있습니다.[80] 그러나 ZFS 풀은 VDEV 전체에 스트라이프(RAID 0)를 효과적으로 생성하므로 RAID 50 또는 RAID 60과 동등한 수준이 됩니다.
  • 최상위 vdev의 디바이스 수를 재구성하려면 기존 미러에 중복성을 추가하는 것을 제외하고 데이터를 오프라인으로 복사하고 풀을 삭제하며 풀을 새로운 최상위 vdev 구성으로 다시 생성해야 합니다. 언제든지 수행할 수 있거나 모든 최상위 vdev가 중복성이 충분한 미러인 경우 zpool split[81] 명령을 사용하여 풀의 각 최상위 vdev에서 vdev를 제거하여 동일한 데이터로 두 번째 풀을 생성할 수 있습니다.
  • ZFS 스토리지 풀의 IOPS 성능은 ZFS 레이드가 적절하게 구성되지 않으면 저하될 수 있습니다. 이것은 어떤 식으로든 모든 유형의 RAID에 적용됩니다. zpool이 RAID Z2에서 8개의 디스크로 구성된 한 그룹의 디스크로만 구성된 경우 IOPS 성능은 단일 디스크의 성능과 같습니다(쓰기 속도는 6개의 디스크와 동일하지만 랜덤 읽기 속도는 단일 디스크와 유사합니다). 그러나 이러한 IOPS 성능 문제를 완화할 수 있는 방법이 있습니다. 예를 들어 SSD를 L2ARC 캐시로 추가하면 IOPS가 100,000초로 증가할 수 있습니다.[82] 간단히 말해서, RAID Z를 사용하는 경우 zpool은 여러 그룹의 vdev로 구성되며, 각 vdev는 8~12개의 디스크로 구성됩니다. IOPS 성능은 단일 디스크의 성능과 비슷하므로 단일 대형 vdev(예: 20개 디스크)로 zpool을 만드는 것은 권장되지 않습니다. 이는 복원기 시간이 매우 길다는 것을 의미하기 때문입니다(향후 대용량 드라이브의 경우 몇 주).
  • ZFS RAID에서 장애가 발생한 디스크의 복구(복구)는 ZFS에만 적용되는 것이 아니라 오랜 시간이 걸릴 수 있으며, 이는 어떤 방식으로든 모든 유형의 RAID에 적용됩니다. 즉, 매우 큰 볼륨은 심각한 데이터 손상 또는 장애 발생 후 복구하거나 완전한 이중화로 복구하는 데 며칠이 걸릴 수 있으며, 이 기간 동안에는 특히 복구 작업이 시스템 전체에 추가적인 스트레스를 주기 때문에 두 번째 Disk 장애가 발생할 수 있습니다. 따라서 RAID Z1(RAID 5와 유사)과 같이 단일 Disk 장애의 복구만 가능한 구성은 피해야 합니다. 따라서 대용량 디스크의 경우 RAID Z2(2개 디스크 장애 허용) 또는 RAID Z3(3개 디스크 장애 허용)를 사용해야 합니다.[83] ZFS RAID는 디스크를 교체할 때 실시간 데이터와 메타데이터만 재구성하고 블랭크 및 가비지 블록을 포함한 디스크 전체를 재구성하는 방식으로 기존 RAID와 다릅니다. 즉, 부분적으로만 가득 찬 ZFS 풀의 멤버 디스크를 교체하는 데는 기존 RAID에 비해 시간이 비례적으로 적게 소요됩니다.[66]

데이터 복구

ZFS는 파일 시스템 자체가 자체 수리하도록 설계되었기 때문에 fsck와 같은 도구와 함께 제공되지 않습니다. 스토리지 설계 및 데이터 이중화에 충분한 주의를 기울여 스토리지 풀을 구축한 이상 fsck와 같은 기본 툴은 필요하지 않았습니다. 그러나 하드웨어가 부실하거나 설계나 중복성이 부족하거나 불행한 사고로 인해 풀이 손상된 경우 ZFS가 풀을 장착할 수 없을 정도로 기존에는 더 발전된 다른 도구가 없었기 때문에 최종 사용자는 심하게 손상된 풀에서 저장된 데이터를 부분적으로 복구할 수 있었습니다.

현대 ZFS는 시간이 지남에 따라 이러한 상황이 상당히 개선되었으며, 다음과 같은 기능을 계속 수행하고 있습니다.

  • 캐싱 장치를 제거하거나 갑자기 고장이 나도 풀 손실은 더 이상 발생하지 않습니다. (최악의 경우, ZIL의 손실은 매우 최근 트랜잭션을 손실할 수 있지만, ZIL은 보통 몇 초 이상의 최근 트랜잭션을 저장하지 않습니다. L2ARC 캐시의 손실은 데이터에 영향을 미치지 않습니다.)
  • 풀을 마운트할 수 없는 경우 최신 버전의 ZFS는 풀을 복구할 수 있는 가장 최근 일관된 지점을 식별하려고 시도할 것이며, 컨텐츠에 대한 가장 최근의 변경 사항 중 일부를 손실하는 비용을 감수해야 합니다. Copy on write는 최상위 레코드 및 메타데이터를 포함한 이전 버전의 데이터가 대체되더라도 여전히 존재할 수 있으며, 이 경우 풀을 기반으로 일관된 상태로 되돌릴 수 있음을 의미합니다. 데이터가 오래될수록 적어도 일부 블록은 덮어쓰게 되고 일부 데이터는 복구할 수 없기 때문에 풀을 다시 감는 기능에는 한계가 있습니다.
  • 비공식적으로 ZFS가 풀을 마운트할 수 없는 이유를 조사하고 풀을 강제로 마운트하는 데 필요한 수동 변경 사항을 사용자 또는 개발자에게 안내하는 도구가 존재합니다. 여기에는 zdb(ZFS 디버그)를 사용하여 풀에서 유효한 가져오기 지점을 찾거나, dtrace 등을 사용하여 마운트 실패를 유발하는 문제를 식별하거나, 마운트 프로세스를 중단하게 하는 상태 검사를 수동으로 무시하고 손상된 풀을 마운트할 수 있습니다.
  • 2018년 3월 현재 OpenZFS 내에서 상당히 향상된 다양한 방법이 점차 출시되고 있습니다. 여기에는 다음이 포함됩니다.[84]
  • 손상된 풀 문제의 진단 및 수정을 단순화하기 위해 코드 리팩토링, 마운트 장애에 대한 보다 상세한 진단 및 디버그 정보.
  • 저장된 풀 구성을 신뢰하거나 신뢰하지 않는 기능입니다. 이 기능은 특히 강력합니다. 최상위 vdev가 없거나 결함이 있는 경우, 최상위 데이터가 의심되는 경우에도 풀을 장착할 수 있으며, 변경 사항이 문제와 연결된 경우 풀 구성 변경 사항을 넘어서는 것도 가능합니다. 손상된 풀을 마운트하면 안전을 위해 읽기 쉬운 파일을 복사할 수 있으며, 풀의 다른 곳에 저장된 복사본을 사용하여 누락된 vdev에 대해서도 데이터를 다시 생성할 수 있습니다.
  • 한 풀에 필요한 디스크가 실수로 제거되어 다른 풀에 추가된 상황을 수정하는 기능으로 인해 첫 번째 풀과 관련된 메타데이터가 손실되어 읽을 수 없게 됩니다.

OpenZFS 및 ZFS

Oracle Corporation은 2010년 Sun 인수 이후 ZFS와 OpenSolaris의 공개 개발을 중단했습니다. 일부 개발자들은 OpenSolaris의 마지막 공개 릴리스를 Illumos 프로젝트로 전환했습니다. ZFS에 존재하는 상당한 이점 때문에, ZFS는 다양한 기능과 명령어를 가진 여러 다른 플랫폼으로 포팅되었습니다. 개발 노력을 조정하고 단편화를 방지하기 위해 OpenZFS는 2013년에 설립되었습니다.

ZFS의 주요 설계자 중 한 명인 Matt Ahrens에 따르면 원래 OpenSolaris ZFS 코드의 50% 이상이 OpenZ에서 대체되었습니다.FS는 2019년 현재 커뮤니티 기여를 하고 있으며, "오라클 ZFS"와 "오픈 ZFS"를 정치적, 기술적으로 양립할 수 없게 만들고 있습니다.[85]

상용 및 오픈 소스 제품

  • 2008년: Sun은 ZFS 기반 7000 시리즈 스토리지 어플라이언스 라인을 출하했습니다.[86]
  • 2013년: Oracle은 ZFS 기반 파일러 ZS3 시리즈를 출하하여 그 중 하나로 SPC-2 벤치마크에서 1위를 차지했습니다.[87]
  • 2013: iXsystems는 기업용 SOHO 및 TrueNAS용 FreeNAS(현재 TrueNAS CORE)라는 ZFS 기반 NAS 장치를 출하합니다.[88][89]
  • 2014: Netgear는 Ready라고 불리는 ZFS 기반 NAS 장치 라인을 출하합니다.기업에서 사용할 수 있도록 설계된 DATA.[90]
  • 2015: rsync.net 에서는 고객이 zfs send 및 zfs receive를 사용하여 자신의 zpool을 프로비저닝하고 데이터를 수출입할 수 있는 클라우드 스토리지 플랫폼을 발표합니다.
  • 2020: iXsystems 기업용 SOHO 및 TrueNAS를 위한 TrueNAS Scale(트루나스 스케일)이라는 ZFS 기반 하이퍼컨버전스 소프트웨어의 개발을 시작합니다.[89]

Oracle Corporation, 비공개 소스 및 포킹(2010년부터)

2010년 1월, Oracle Corporation은 Sun Microsystems를 인수하고 OpenSolaris 배포 및 오픈 소스 개발 모델을 빠르게 중단했습니다.[93][94] 2010년 8월, 오라클은 솔라리스 OS/네트워킹 저장소의 소스 코드에 대한 공개 업데이트를 중단했고, 사실상 솔라리스 11을 비공개 소스 독점 운영 체제로 전환했습니다.[95]

Solaris와 OpenSolaris의 변화하는 환경에 대응하여, 일부 핵심 Solaris 엔지니어들이 Solaris의 오픈 소스 버전을 계속 개발하고 Sun이 아직 오픈 소스가 아닌 부분의 오픈 소싱을 완료하기 위한 공동의 노력으로 2010년 8월 3일 목요일에 웹 세미나를[96] 통해 일루미노스 프로젝트를 시작했습니다.[97] Illumos는 501(c)6 무역 협회로서 캘리포니아 주에 통합된 재단, Illumos Foundation으로 설립되었습니다. 원래 계획은 일루미노스가 분배나 포크가 되지 않을 것이라고 명시적으로 말했습니다. 그러나 오라클이 OpenSolaris를 중단한다고 발표한 후, Solaris ON의 최종 버전을 포크할 계획이 세워졌고, 일루미노스가 자체 운영 체제로 진화할 수 있게 되었습니다.[98] 따라서 오픈솔라리스의 일부로서 오픈 소스 버전의 ZFS는 일루미노스 내에 통합되어 있었습니다.

ZFS는 Solaris 뿐만 아니라 수많은 플랫폼에서 널리 사용되었습니다. 따라서 2013년에는 ZFS의 오픈 소스 버전에 대한 개발 작업 조정이 우산 프로젝트인 OpenZFS로 넘어갔습니다. 오픈지FS 프레임워크를 사용하면 모든 이해 관계자가 공동으로 핵심 ZFS 코드베이스를 개발하는 동시에 ZFS가 자체 시스템 내에서 기능하고 통합하는 데 필요한 특정 추가 코드를 개별적으로 유지할 수 있습니다.

버전이력

나중 기록은 Oracle ZFS § 버전 기록 및 OpenZ를 참조하십시오.FS § 버전 기록.
범례:
구출시
최신 FOSS 안정적인 출시
ZFS 파일 시스템 버전 번호 출고일자 중요한 변화
1 오픈 솔라리스 네바다[99] 빌딩 36 첫출시
2 오픈솔라리스 네바다 b69 향상된 디렉토리 항목입니다. 특히 디렉토리 항목은 개체 유형을 저장합니다. 예를 들어 개체 번호 외에 파일, 디렉터리, 명명된 파이프 등입니다.
3 오픈솔라리스 네바다 b77 SMB를 통한 ZFS 파일 시스템 공유 지원. Case insensitive 지원. 시스템 속성 지원. 통합 안티바이러스 지원.
4 오픈솔라리스 네바다 b114 속성: 사용자 할당량, 그룹 할당량, 사용자 사용 및 그룹 사용
5 오픈솔라리스 네바다 b137 시스템 특성; 이제 고유한 개체 유형으로 심볼링됨
ZFS 풀 버전 번호 출고일자 중요한 변화
1 오픈솔라리스 네바다[99] b36 첫출시
2 오픈솔라리스 네바다 b38 디토 블록
3 오픈솔라리스 네바다 b42 핫 스페어, 이중 패리티 RAID-Z(raidz2), 향상된 RAID-Z 회계
4 오픈솔라리스 네바다 b62 zpool 히스토리
5 오픈솔라리스 네바다 b62 ZFS 데이터 세트에 대한 gzip 압축
6 오픈솔라리스 네바다 b62 "bootfs" 풀 속성
7 오픈솔라리스 네바다 b68 ZIL: 별도의 Intent Log 장치 또는 장치를 지정할 수 있는 기능 추가
8 오픈솔라리스 네바다 b69 일반 사용자에게 zfs(1M) 관리 작업 위임 기능
9 오픈솔라리스 네바다 b77 CIFS 서버 지원, 데이터셋 할당량
10 오픈솔라리스 네바다 b77 디바이스를 스토리지 풀에 "캐시 디바이스"로 추가할 수 있습니다.
11 오픈솔라리스 네바다 b94 zpool scrub/resilver 성능 향상
12 오픈솔라리스 네바다 b96 스냅샷 속성
13 오픈솔라리스 네바다 b98 속성: 스냅샷에서 사용, 어린이에서 사용, 예약에서 사용, 데이터셋에서 사용
14 오픈솔라리스 네바다 b103 passthrough-xacline 속성 지원 상속
15 오픈솔라리스 네바다 b114 속성: 사용자 할당량, 그룹 할당량, 사용자 사용 및 그룹 사용, FS v4 필요
16 오픈솔라리스 네바다 b116 STMF 속성 지원
17 오픈솔라리스 네바다 b120 3중 패리티 RAID-Z
18 오픈솔라리스 네바다 b121 ZFS 스냅샷 홀드
19 오픈솔라리스 네바다 b125 ZFS 로그 장치 제거
20 오픈솔라리스 네바다 b128 ZFS 풀 버전 21에서 ZFS 중복제거 속성을 지원하는 데 필요한 zle 압축 알고리즘으로, 동시에 출시된 것입니다.
21 오픈솔라리스 네바다 b128 중복제거
22 오픈솔라리스 네바다 b128 zfs가 속성을 수신합니다.
23 오픈솔라리스 네바다 b135 슬림 ZIL
24 오픈솔라리스 네바다 b137 시스템 속성. 이제 심링크는 자신의 개체 유형을 나타냅니다. 또한 FS v5가 필요합니다.
25 오픈솔라리스 네바다 b140 향상된 풀 스크러빙 및 복원 통계
26 오픈솔라리스 네바다 b141 스냅샷 삭제 성능 향상
27 오픈솔라리스 네바다 b145 향상된 스냅샷 생성 성능(특히 재귀적 스냅샷)
28 오픈솔라리스 네바다 b147 여러 개의 가상 장치 교체

참고: 2005년 Solaris 10이 출시된 이후 Sun이 개발 중인 Solaris 버전은 코드명 'Nevada'로 OpenSolaris 코드베이스에서 파생되었습니다. 'Solaris Nevada'는 차세대 Solaris OS가 Solaris 10의 뒤를 이을 코드명이며, 이 새로운 코드는 새로운 OpenSolaris 'Nevada' 스냅샷 빌드에 연속적으로 풀링되었습니다.[99] Open Solaris는 현재 단종되었고 Open Indiana는 그것으로부터 분리되었습니다.[100][101] OpenSolaris의 최종 빌드(b134)는 Oracle(2010-Nov-12)에서 Solaris 11 Express로의 업그레이드 경로로 게시되었습니다.

운영체제 지원

ZFS를 지원하는 운영 체제, 배포 및 추가 기능, 지원하는 zpool 버전 및 기반 Solaris 빌드 목록(있는 경우):

OS Zpool 버전 태양/오라클 빌드 # 평.
Oracle Solaris 11.4 49 11.4.51 (11.4 SRU 51)[102]
Oracle Solaris 11.3 37 0.5.11-0.175.3.1.0.5.0
Oracle Solaris 101/13 (U11) 32
Oracle Solaris 11.2 35 0.5.11-0.175.2.0.0.42.0
Oracle Solaris 11 2011.11 34 b175
Oracle Solaris Express 11 2010.11 31 b151a 테스트용으로만 라이센스가 부여됨
OpenSolaris 2009.06 14 b111b
Solaris 열기(마지막 개발자) 22 b134
오픈 인디아나 5000 b147 illumos 기반 배포; 빌드 코드의 이름을 'b151a'로 지정하는 이름 충돌을 만듭니다.
Nexenta Core 3.0.1 26 b134+ GNU 사용자 국가
NexentaStor 커뮤니티 3.0.1 26 b134+ 최대 18TB, 웹 관리자
넥센타스토르 커뮤니티 3.1.0 28 b134+ GNU 사용자 국가
NexentaStor 커뮤니티 4.0 5000 b134+ 최대 18TB, 웹 관리자
넥센타스토어 엔터프라이즈 28 b134 + 무료가 아님, 웹 관리자
GNU/kFreeBSD "Squeeze"(지원되지 않음) 14 패키지 "zfsutils" 필요
GNU/kFreeBSD "Wheezy-9"(지원되지 않음) 28 패키지 "zfsutils" 필요
프리BSD 5000
zfs-fuse 0.7.2 23 성능 문제로 어려움을 겪음; 기능 상실
ZFS on Linux 0.6.5.8 5000 0.6.0 릴리스 후보에 POSIX 계층이 있습니다.
리눅스 기반 KQ Infotech의 ZFS 28 비활성; 리눅스에서 LLNL 지원 ZFS에 통합된 코드
BeleniX 0.8b1 14 b111 한때 OpenSolaris를 기반으로 한 소규모 라이브 CD 배포
Schillix 0.7.2 28 b147 OpenSolaris 기반의 SchilliX-ON 0.8.0과 같이 작은 크기의 라이브 CD 배포
스톰OS "하일" 한때 Nexenta Core 2.0+, Debian Linux를 기반으로 배포되었으며, Dyson OS로 대체되었습니다.
자리스 한때 OpenSolaris 기반이었던 일본 Solaris 배포판
밀라X 0.5 20 b128a 한때 OpenSolaris를 기반으로 한 소규모 라이브 CD 배포
FreeNAS 8.0.2 / 8.2 15
FreeNAS 8.3.0 28 FreeBSD 8.3 기반
FreeNAS 9.1.0+ 5000 FreeBSD 9.1+ 기준
XigmaNAS 11.4.0.4/12.2.0.4 5000 FreeBSD 11.4/12.2 기준
Korona 4.5.0 22 b134 KDE
EON NAS (v0.6) 22 b130 내장형 NAS
EON NAS (v1.0beta) 28 b151a 내장형 NAS
잽싸게 28/5000 일루미노스/솔라리스 스토리지 어플라이언스; Open Indiana(Hipster), OmniOS, Solaris 11, Linux(ZFS 관리)
옴니오스 CE 28/5000 일루미노스-옴니오스 지점 Illumos, 커뮤니티 기반의 최소한의 안정적/LTS 스토리지 서버 배포
스마트 OS 28/5000 일루미노스 b151+ Illumos(USB/CD 부팅), 클라우드 및 하이퍼바이저 사용(KVM)에 기반한 최소 라이브 배포
macOS 10.5, 10.6, 10.7, 10.8, 10.9 5000 MacZFS를 통해, OpenZ로 대체됨OS X의 FS
macOS 10.6, 10.7, 10.8 28 ZEVO를 통해, OpenZ로 대체됨OS X의 FS
넷BSD 22
미드나잇BSD 6
Proxmox VE 5000 2014년 이후 네이티브 지원, pve.proxmox.com/wiki/ZFS_on_Linux
Ubuntu Linux 16.04 LTS+ 5000 설치 가능한 이진 모듈을 통한 네이티브 지원, wiki.ubuntu.com/ZFS
ZFSGuru 10.1.100 5000

참고 항목

메모들

  1. ^ RAID 7은 표준 RAID 레벨은 아니지만 3 이상의 패리티 RAID 구성에[37] 대한 캐치올(catch-all) 용어로 제안되었습니다.

참고문헌

  1. ^ a b "What Is ZFS?". Oracle Solaris ZFS Administration Guide. Oracle. Archived from the original on March 4, 2016. Retrieved December 29, 2015.
  2. ^ "ZFS on Linux Licensing". GitHub. Retrieved May 17, 2020.
  3. ^ "The OpenZFS project launches". LWN.net. September 17, 2013. Archived from the original on October 4, 2013. Retrieved October 1, 2013.
  4. ^ "OpenZFS Announcement". OpenZFS. September 17, 2013. Archived from the original on April 2, 2018. Retrieved September 19, 2013.
  5. ^ 2013년 12월 24일 Wayback Machine "OpenZ"에서 open-zfs.org /History 아카이브FS는 ZFS 프로젝트의 진정한 오픈 소스입니다 [...] Effects of the Fork (2010년부터 현재까지)"
  6. ^ Sean Michael Kerner (September 18, 2013). "LinuxCon: OpenZFS moves Open Source Storage Forward". infostor.com. Archived from the original on March 14, 2014. Retrieved October 9, 2013.
  7. ^ "The OpenZFS project launches". LWN.net. September 17, 2013. Archived from the original on October 11, 2016. Retrieved October 1, 2013.
  8. ^ "OpenZFS – Communities co-operating on ZFS code and features". freebsdnews.net. September 23, 2013. Archived from the original on October 14, 2013. Retrieved March 14, 2014.
  9. ^ a b "19.4. zfs Administration". www.freebsd.org. Archived from the original on February 23, 2017. Retrieved February 22, 2017.
  10. ^ Salus, Peter (1994). A Quarter Century of Unix. Addison-Wesley. pp. 199–200. ISBN 0-201-54777-5.
  11. ^ "What are SunOS and Solaris?". Knowledge Base. Indiana University Technology Services. May 20, 2013. Retrieved November 10, 2014.
  12. ^ Brown, David. "A Conversation with Jeff Bonwick and Bill Moore". ACM Queue. Association for Computing Machinery. Archived from the original on July 16, 2011. Retrieved November 17, 2015.
  13. ^ "ZFS: the last word in file systems". Sun Microsystems. September 14, 2004. Archived from the original on April 28, 2006. Retrieved April 30, 2006.
  14. ^ Matthew Ahrens (November 1, 2011). "ZFS 10 year anniversary". Archived from the original on June 28, 2016. Retrieved July 24, 2012.
  15. ^ a b Bonwick, Jeff (October 31, 2005). "ZFS: The Last Word in Filesystems". blogs.oracle.com. Archived from the original on June 19, 2013. Retrieved June 22, 2013.
  16. ^ "Sun Celebrates Successful One-Year Anniversary of OpenSolaris". Sun Microsystems. June 20, 2006. Archived from the original on September 28, 2008. Retrieved April 30, 2018.
  17. ^ Michael Singer (January 25, 2005). "Sun Cracks Open Solaris". InternetNews.com. Retrieved April 12, 2010.
  18. ^ "ZFS FAQ at OpenSolaris.org". Sun Microsystems. Archived from the original on May 15, 2011. Retrieved May 18, 2011. The largest SI prefix we liked was 'zetta' ('yotta' was out of the question)
  19. ^ Jeff Bonwick (May 3, 2006). "You say zeta, I say zetta". Jeff Bonwick's Blog. Archived from the original on February 23, 2017. Retrieved April 21, 2017. So we finally decided to unpimp the name back to ZFS, which doesn't stand for anything.
  20. ^ "Oracle and NetApp dismiss ZFS lawsuits". theregister.co.uk. September 9, 2010. Archived from the original on September 9, 2017. Retrieved December 24, 2013.
  21. ^ Extended file system(Ext)에는 UFS에서 복사된 메타데이터 구조가 있습니다. (프랑스어로)
  22. ^ Vijayan Prabhakaran (2006). "IRON FILE SYSTEMS" (PDF). Doctor of Philosophy in Computer Sciences. University of Wisconsin-Madison. Archived (PDF) from the original on April 29, 2011. Retrieved June 9, 2012.
  23. ^ "Parity Lost and Parity Regained". Archived from the original on June 15, 2010. Retrieved November 29, 2010.
  24. ^ "An Analysis of Data Corruption in the Storage Stack" (PDF). Archived (PDF) from the original on June 15, 2010. Retrieved November 29, 2010.
  25. ^ "Impact of Disk Corruption on Open-Source DBMS" (PDF). Archived (PDF) from the original on June 15, 2010. Retrieved November 29, 2010.
  26. ^ Kadav, Asim; Rajimwale, Abhishek. "Reliability Analysis of ZFS" (PDF). Archived (PDF) from the original on September 21, 2013. Retrieved September 19, 2013.
  27. ^ a b c Yupu Zhang; Abhishek Rajimwale; Andrea Arpaci-Dusseau; Remzi H. Arpaci-Dusseau (2010). "End-to-end data integrity for file systems: a ZFS case study" (PDF). USENIX Conference on File and Storage Technologies. CiteSeerX 10.1.1.154.3979. S2CID 5722163. Wikidata Q111972797. Retrieved December 6, 2010.
  28. ^ Larabel, Michael. "Benchmarking ZFS and UFS On FreeBSD vs. EXT4 & Btrfs On Linux". Phoronix Media 2012. Archived from the original on November 29, 2016. Retrieved November 21, 2012.
  29. ^ Larabel, Michael. "Can DragonFlyBSD's HAMMER Compete With Btrfs, ZFS?". Phoronix Media 2012. Archived from the original on November 29, 2016. Retrieved November 21, 2012.
  30. ^ a b c Bonwick, Jeff (December 8, 2005). "ZFS End-to-End Data Integrity". blogs.oracle.com. Archived from the original on April 3, 2012. Retrieved September 19, 2013.
  31. ^ Cook, Tim (November 16, 2009). "Demonstrating ZFS Self-Healing". blogs.oracle.com. Archived from the original on August 12, 2011. Retrieved February 1, 2015.
  32. ^ Ranch, Richard (May 4, 2007). "ZFS, copies, and data protection". blogs.oracle.com. Archived from the original on August 18, 2016. Retrieved February 2, 2015.
  33. ^ a b "zpoolconcepts.7 — OpenZFS documentation". openzfs.github.io. Retrieved April 5, 2023.
  34. ^ "ZFS Without Tears: Using ZFS without ECC memory". www.csparks.com. December 2015. Archived from the original on January 13, 2021. Retrieved June 16, 2020.
  35. ^ wdc.custhelp.com. "Difference between Desktop edition and RAID (Enterprise) edition drives". Archived from the original on January 5, 2015. Retrieved September 8, 2011.
  36. ^ a b c d Bonwick, Jeff (November 17, 2005). "RAID-Z". Jeff Bonwick's Blog. Oracle Blogs. Archived from the original on December 16, 2014. Retrieved February 1, 2015.
  37. ^ a b Leventhal, Adam (December 17, 2009). "Triple-Parity RAID and Beyond". Queue. 7 (11): 30. doi:10.1145/1661785.1670144.
  38. ^ "ZFS Raidz Performance, Capacity and integrity". calomel.org. Archived from the original on November 27, 2017. Retrieved June 23, 2017.
  39. ^ "Why RAID 6 stops working in 2019". ZDNet. February 22, 2010. Archived from the original on October 31, 2014. Retrieved October 26, 2014.
  40. ^ "ZFS에 대해 fsck 유틸리티와 동등한 수준이 존재하지 않습니다. 이 유틸리티는 기존에는 파일 시스템 복구와 파일 시스템 검증이라는 두 가지 목적을 수행했습니다."
  41. ^ "ZFS Scrubs". freenas.org. Archived from the original on November 27, 2012. Retrieved November 25, 2012.
  42. ^ "또한 장치를 교체하거나 일시적으로 풀의 중복성을 줄이기 전에 스크럽을 실행하여 모든 장치가 현재 작동하는지 확인해야 합니다."
  43. ^ Jeff Bonwick. "128-bit storage: are you high?". oracle.com. Archived from the original on May 29, 2015. Retrieved May 29, 2015.
  44. ^ "ZFS: Boils the Ocean, Consumes the Moon (Dave Brillhart's Blog)". Archived from the original on December 8, 2015. Retrieved December 19, 2015.
  45. ^ "Solaris ZFS Administration Guide". Oracle Corporation. Archived from the original on January 13, 2021. Retrieved February 11, 2011.
  46. ^ "Encrypting ZFS File Systems". Archived from the original on June 23, 2011. Retrieved May 2, 2011.
  47. ^ "Having my secured cake and Cloning it too (aka Encryption + Dedup with ZFS)". Archived from the original on May 29, 2013. Retrieved October 9, 2012.
  48. ^ "ZFS – Debian Wiki". wiki.debian.org. Archived from the original on September 8, 2019. Retrieved December 10, 2019.
  49. ^ "Solaris ZFS Enables Hybrid Storage Pools—Shatters Economic and Performance Barriers" (PDF). Sun.com. September 7, 2010. Archived (PDF) from the original on October 17, 2011. Retrieved November 4, 2011.
  50. ^ Gregg, Brendan. "ZFS L2ARC". Brendan's blog. Dtrace.org. Archived from the original on November 6, 2011. Retrieved October 5, 2012.
  51. ^ Gregg, Brendan (October 8, 2009). "Hybrid Storage Pool: Top Speeds". Brendan's blog. Dtrace.org. Archived from the original on April 5, 2016. Retrieved August 15, 2017.
  52. ^ "Solaris ZFS Performance Tuning: Synchronous Writes and the ZIL". Constantin.glez.de. July 20, 2010. Archived from the original on June 23, 2012. Retrieved October 5, 2012.
  53. ^ a b c "Release zfs-0.8.0". GitHub. OpenZFS. May 23, 2019. Retrieved July 3, 2021.
  54. ^ "ZFS On-Disk Specification" (PDF). Sun Microsystems, Inc. 2006. Archived from the original (PDF) on December 30, 2008. 섹션 2.4를 참조하십시오.
  55. ^ "RAIDZ — OpenZFS documentation". openzfs.github.io. Retrieved February 9, 2023.
  56. ^ Eric Sproul (May 21, 2009). "ZFS Nuts and Bolts". slideshare.net. pp. 30–31. Archived from the original on June 22, 2014. Retrieved June 8, 2014.
  57. ^ "ZFS Deduplication". blogs.oracle.com. Archived from the original on December 24, 2019. Retrieved November 25, 2019.
  58. ^ Gary Sims (January 4, 2012). "Building ZFS Based Network Attached Storage Using FreeNAS 8". TrainSignal Training. TrainSignal, Inc. Archived from the original (Blog) on May 7, 2012. Retrieved June 9, 2012.
  59. ^ Ray Van Dolson (May 2011). "[zfs-discuss] Summary: Deduplication Memory Requirements". zfs-discuss mailing list. Archived from the original on April 25, 2012.
  60. ^ "ZFSTuningGuide". Archived from the original on January 16, 2012. Retrieved January 3, 2012.
  61. ^ Chris Mellor (October 12, 2012). "GreenBytes brandishes full-fat clone VDI pumper". The Register. Archived from the original on March 24, 2013. Retrieved August 29, 2013.
  62. ^ Chris Mellor (June 1, 2012). "Newcomer gets out its box, plans to sell it cheaply to all comers". The Register. Archived from the original on August 12, 2013. Retrieved August 29, 2013.
  63. ^ Chris Mellor (December 11, 2014). "Dedupe, dedupe... dedupe, dedupe, dedupe: Oracle polishes ZFS diamond". The Register. Archived from the original on July 7, 2017. Retrieved December 17, 2014.
  64. ^ "Checksums and Their Use in ZFS". github.com. September 2, 2018. Archived from the original on July 19, 2019. Retrieved July 11, 2019.
  65. ^ "Solaris ZFS Administration Guide". Chapter 6 Managing ZFS File Systems. Archived from the original on February 5, 2011. Retrieved March 17, 2009.
  66. ^ a b "Smokin' Mirrors". blogs.oracle.com. May 2, 2006. Archived from the original on December 16, 2011. Retrieved February 13, 2012.
  67. ^ "ZFS Block Allocation". Jeff Bonwick's Weblog. November 4, 2006. Archived from the original on November 2, 2012. Retrieved February 23, 2007.
  68. ^ "Ditto Blocks — The Amazing Tape Repellent". Flippin' off bits Weblog. May 12, 2006. Archived from the original on May 26, 2013. Retrieved March 1, 2007.
  69. ^ "Adding new disks and ditto block behaviour". Archived from the original on August 23, 2011. Retrieved October 19, 2009.
  70. ^ "OpenSolaris.org". Sun Microsystems. Archived from the original on May 8, 2009. Retrieved May 22, 2009.
  71. ^ "What's new in Solaris 11 Express 2010.11" (PDF). Oracle. Archived (PDF) from the original on November 16, 2010. Retrieved November 17, 2010.
  72. ^ "10. Sharing — FreeNAS User Guide 9.3 Table of Contents". doc.freenas.org. Archived from the original on January 7, 2017. Retrieved February 23, 2017.
  73. ^ "Ars walkthrough: Using the ZFS next-gen filesystem on Linux". arstechnica.com. Archived from the original on February 10, 2017. Retrieved June 19, 2017.
  74. ^ "Bug ID 4852783: reduce pool capacity". OpenSolaris Project. Archived from the original on June 29, 2009. Retrieved March 28, 2009.
  75. ^ Goebbels, Mario (April 19, 2007). "Permanently removing vdevs from a pool". zfs-discuss (Mailing list).[permanent dead link] 2021년 1월 13일 Wayback Machine에서 아카이브 링크
  76. ^ 향후 vdev 제거에 대한 Chris Siebenmann 정보 2016년 8월 11일 Univ Toronto, Wayback Machine에서 보관됨, 블로그, 인용: Alex Rece의 비공식 트위터 발표 2016년 8월 11일 Wayback Machine에서 보관됨
  77. ^ "Data Management Features – What's New in Oracle® Solaris 11.4". Archived from the original on September 24, 2019. Retrieved October 9, 2019.
  78. ^ "Expand-O-Matic RAID Z". Adam Leventhal. April 7, 2008. Archived from the original on December 28, 2011. Retrieved April 16, 2012.
  79. ^ "ZFS Toy". SourceForge.net. Retrieved April 12, 2022.
  80. ^ "zpoolconcepts(7)". OpenZFS documentation. OpenZFS. June 2, 2021. Retrieved April 12, 2021. Virtual devices cannot be nested, so a mirror or raidz virtual device can only contain files or disks. Mirrors of mirrors (or other combinations) are not allowed.
  81. ^ "zpool(1M)". Download.oracle.com. June 11, 2010. Archived from the original on January 13, 2021. Retrieved November 4, 2011.
  82. ^ brendan (December 2, 2008). "A quarter million NFS IOPS". Oracle Sun. Archived from the original on December 17, 2011. Retrieved January 28, 2012.
  83. ^ Leventhal, Adam. "Triple-Parity RAID Z". Adam Leventhal's blog. Archived from the original on April 16, 2011. Retrieved December 19, 2013.
  84. ^ "Turbocharging ZFS Data Recovery". Archived from the original on November 29, 2018. Retrieved November 29, 2018.
  85. ^ "ZFS and OpenZFS". iXSystems. Retrieved May 18, 2020.
  86. ^ "Sun rolls out its own storage appliances". techworld.com.au. November 11, 2008. Archived from the original on November 13, 2013. Retrieved November 13, 2013.
  87. ^ Chris Mellor (October 2, 2013). "Oracle muscles way into seat atop the benchmark with hefty ZFS filer". theregister.co.uk. Archived from the original on July 7, 2017. Retrieved July 7, 2014.
  88. ^ "Unified ZFS Storage Appliance built in Silicon Valley by iXsystem". ixsystems.com. Archived from the original on July 3, 2014. Retrieved July 7, 2014.
  89. ^ a b "TrueNAS 12 & TrueNAS SCALE are officially here!". ixsystems.com. Retrieved January 2, 2021.
  90. ^ "ReadyDATA 516 – Unified Network Storage" (PDF). netgear.com. Archived (PDF) from the original on July 15, 2014. Retrieved July 7, 2014.
  91. ^ Jim Salter (December 17, 2015). "rsync.net: ZFS Replication to the cloud is finally here—and it's fast". arstechnica.com. Archived from the original on August 22, 2017. Retrieved August 21, 2017.
  92. ^ rsync.net, Inc. "Cloud Storage with ZFS send and receive over SSH". rsync.net. Archived from the original on July 21, 2017. Retrieved August 21, 2017.
  93. ^ Steven Stallion / Oracle (August 13, 2010). "Update on SXCE". Iconoclastic Tendencies. Archived from the original on November 9, 2020. Retrieved April 30, 2018.
  94. ^ Alasdair Lumsden. "OpenSolaris cancelled, to be replaced with Solaris 11 Express". osol-discuss (Mailing list). Archived from the original on August 16, 2010. Retrieved November 24, 2014.
  95. ^ Solaris는 여전히 열려 있지만 OpenSolaris distro는 Ryan Paul의 Wayback Machine on Ars Technica에서 2017년 9월 5일(2010년 8월 16일)에 죽은 상태입니다.
  96. ^ Garrett D'Amore (August 3, 2010). "Illumos - Hope and Light Springs Anew - Presented by Garrett D'Amore" (PDF). illumos.org. Retrieved August 3, 2010.
  97. ^ "Whither OpenSolaris? Illumos Takes Up the Mantle". Archived from the original on September 26, 2015.
  98. ^ Garrett D'Amore (August 13, 2010). "The Hand May Be Forced". Retrieved November 14, 2013.
  99. ^ a b c "Sun Microsystems가 관리하는 동안, Solaris Nevada(Solaris 10을 계승할 차세대 Solaris OS의 코드명)의 스냅샷이 격주로 생성되었고, 이 새로운 코드는 Genunix.org 에서 제공되는 새로운 OpenSolaris 미리보기 스냅샷으로 풀렸습니다. OpenSolaris의 안정적인 출시는 이러한 Nevada 빌드를 기반으로 합니다."
  100. ^ Ljubuncic, Igor (May 23, 2011). "OpenIndiana — there's still hope". DistroWatch. Archived from the original on October 27, 2012. Retrieved November 21, 2012.
  101. ^ "Welcome to Project OpenIndiana!". Project OpenIndiana. September 10, 2010. Archived from the original on November 27, 2012. Retrieved September 14, 2010.
  102. ^ "ZFS Pool Versions". Oracle Corporation. 2022. Archived from the original on December 21, 2022. Retrieved January 1, 2023.

서지학

외부 링크