| 📁 파일 시스템 | |||||||
| {{{#!wiki style="margin: 0 -10px -5px; min-height: calc(1.5em + 5px);" {{{#!folding [ 펼치기 · 접기 ] {{{#!wiki style="margin: -6px -1px -11px" | <colbgcolor=#f1d592><colcolor=#000>마이크로소프트 | FAT | NTFS | ReFS | |||
| 애플 | HFS | HFS+ | APFS | ||||
| 리눅스 / 유닉스 | ext2 | ext3 | ext4 | ||||
| Btrfs | F2FS | XFS | ZFS | ||||
1. 개요
썬 마이크로시스템즈에서 개발하였고, 솔라리스에 탑재되었다. 지상 최강의 파일 시스템 이라고 일컬어지기도 한다.다음과 같은 기능들을 지원하기 때문.
- 최초의 128비트 파일 시스템 : 228 QiB(2128 바이트)의 용량을 지원한다. 현 세대 저장소 기술을 감안해보면 가히 무한대라 봐도 무방하다.
- 네트워크 지원: iSCSI, CIFS(Samba), NFS를 지원한다.
- SSD 캐시 지원
- 자체 RAID 지원
- Pool 기능 지원
- Silent Corruption 방지
OpenSolarais 10과 함께 오픈소스로 공개되었지만 오라클이 썬 마이크로시스템즈를 인수한 뒤로는 다시 클로즈드 소스가 되었다. 다만 OpenZFS라는 오픈 소스 프로젝트는 계속 ZFS를 개발 및 소스코드 공개를 하고 있다.
2. ARC
Adaptive Replacement Cache의 약어로 최근에 읽거나 쓴 파일들이 1차적으로 위치하는 저장공간이다. cache로서 ZFS가 메모리를 엄청나게 쓰는 주요 원인이 이 ARC이다.ZFS는 ARC의 내용물을 단순히 최근에 읽거나 썼다, 접근 횟수가 많다 뿐만 아니라 hit ratio에 따라 내용물을 스스로 조절하는 메커니즘을 가지고 있다.
기본적으로 램디스크로 주 메모리를 잡아 사용하기 때문에 휘발성이며, 매우 빠르고 기가당 비용상 결코 저렴한 저장소가 아니기 때문에 크기가 한정적이 될수밖에 없다.
이런 hit ratio와 용량의 한계를 극복하기 위한 2차 cache가 후술될 L2ARC다.
3. vdev
vdev는 Virtual Device(가상 장치)의 약어지만 꼭 가상 장치를 뜻하는 것은 아니다. vdev는 zpool을 구성하는 요소로서 zpool과 물리적인 디스크 사이에 존재하는 하나의 추상화된 계층이다. 예를 들어 흔히 우리가 아는 RAID로 형성된 가상 장치 등이 여기에 대응된다. 소프트웨어 RAID와 관련된 ZFS의 vdev에는 다음과 같은 종류들이 있다.- stripe : RAID0 스트라이프 구성이다. 자세한 내용은 RAID 참조.
- mirror : RAID1 미러링 구성이다. 자세한 내용은 RAID 참조.
- raidz1/2/3 : 간단하게 말하면 동일한 크기의 디스크가 묶인 기준으로 패리티 용량을 디스크 1/2/3개씩 두는 RAID 구성. 앞의 두 개는 각각 RAID5/6에 대응된다.
- spare : "핫 스페어"라고도 불리며, 평상시에는 아무 것도 하지 않는 여분의 상태로 남겨져 있다. 그러다가 다른 raidz1/2/3의 구성 디스크 중에 결함이 생기면 그 디스크가 이 스페어 디스크로 자동으로 대체된다.
- cache
cache는 L2ARC로 쓰이는 vdev를 말한다. L2ARC는 Level 2 ARC의 준말로, 시스템의 RAM에 거주하는 캐시인 ARC의 보조로서 동작한다. 짧게 말하면 읽기 캐시로서, 순위가 높은 데이터들을 ARC에 올리고 그 외의 데이터들을 L2ARC로 넣게 된다. 만일 ARC에서 원하는 데이터를 찾지 못하면(ARC의 예측 실패) L2ARC에서 원하는 데이터를 찾고, 또 실패하면(L2ARC의 예측 실패) 그제서야 비로소 zpool을 구성하는 데이터 디스크에 접근해 원하는 데이터를 찾아가게 된다. 당연한 말이지만 L2ARC 또한 zpool을 주로 구성하는 하드 디스크보다 훨씬 빠른 SSD 등을 주로 이용해야 한다. 다만 SLOG에 비해 L2ARC로 얻을 수 있는 성능의 향상은 I/O가 엄청 잦고 부하가 큰 환경이 아니면 적은 편이다. L2ARC는 주로 임의의 위치를 읽는 데이터베이스 등에서 유용하며, 같은 부분이 반복해서 주로 읽히는 경우에 쓰이고, 순차읽기 등에서는 L2ARC로 얻을 수 있는 성능 이득이 없다. 또한 ZFS는 L2ARC의 체크섬 값 등을 보관할 공간을 다시 RAM에 할당하게 되므로, RAM에 비해 너무 L2ARC가 클 경우 RAM 용량이 부족해 스왑이 발생해 도로 성능이 떨어지는 역효과가 일어난다. 보통 시스템 RAM 용량이 64GB 이상은 되어야 L2ARC를 고려할 만하다. - log
log는 SLOG(Seperate intent LOG)를 말한다.
SLOG를 알기 전에 앞서 ZIL(ZFS Intent Log)란 것을 알 필요가 있다. ZIL이란 하드 디스크에 직접 기록되기 전에 앞서 데이터가 먼저 기록되는 쓰기 캐시로서 ZIL로 할당된 용량은 zpool의 저장 가능 용량에 반영되지 않으며 순수히 캐시 용도로만 이용된다. ZFS는 zpool마다 반드시 ZIL이 있다. 보통 하드웨어 RAID 컨트롤러의 경우 이런 쓰기 캐시가 반드시 컨트롤러 내에 존재하지만 ZFS 구성 하드웨어에는 이러한 캐시는 옵션 사항으로써, 반드시 이러한 전용 쓰기 캐시 메모리가 제공된다는 보장이 없다. 이런 경우 ZFS는 zpool의 일부를 ZIL로 할당해 사용한다. 하지만 이 경우 보통 하드 디스크로 구성되는 zpool 특성상 zpool 자체의 탐색 속도가 느릴 수 있으며 zpool의 입출력이 잦은 경우 성능이 떨어지게 된다.
본래 디스크 쓰기 작업은 두 종류로 분류된다. 동기 쓰기와 비동기 쓰기이다. 참고 페이지: Solaris ZFS, Synchronous Writes and the ZIL Explained
먼저 쓰기 작업이 수행되면 운영 체제는 데이터를 먼저 RAM 상의 캐시에 기록한다. 그리고 여기서 비동기 쓰기 작업의 경우 RAM 캐시에 기록된 것까지만 확인한 후 프로그램은 다음 명령을 수행하러 넘어간다. 즉, 플래시 메모리든 하드 디스크든 어딘가에 실제로 데이터가 기록되지 않고 넘어간다. 쓰기 명령 수행 사항과 실제 디스크 상의 데이터가 일치(즉 동기)하지 않을 수 있다. 그래서 이 쓰기 작업을 비동기 쓰기라고 한다. 비동기 쓰기는 느리디 느린 디스크가 작업을 완료할 때까지 프로그램이 다음 명령을 수행하지 않고 대기하지 않게 되므로 프로그램의 실행 속도가 빨라진다. 그러나 예상치 못한 상황(대표적으로 정전) 등이 발생한다면, 비동기 쓰기의 경우 아직 그 내용이 디스크에 기록되지 않았다면 당연히 그 내용은 소실되는 문제가 있다. 이로 인해 비동기 쓰기의 경우 프로그램 상에서 실제로 디스크에 데이터가 기록되었는지 확인하는 작업이 필요하다.
반면, 동기 쓰기의 경우 RAM 캐시에 기록하는 것까지는 동일하지만 이로 끝나지 않고 실제로 SSD나 하드 디스크 등의 비휘발성의 안정된 저장장치에 대해 기록되는 작업까지 그대로 수행한다. 이 쓰기 작업이 완수될 때까지 프로그램은 다음 명령을 수행하지 않고 대기한다. 그래서 동기 쓰기의 경우 쓰기 명령을 했다면 그 명령이 완수되었다면 그 데이터 내용은 반드시 디스크에 기록되었음이 보장된다. 즉, 쓰기 명령 수행사항과 실제 디스크 상의 데이터가 일치(동기)하므로 동기 쓰기라고 한다. 동기 쓰기는 이런 장점이 있지만, 반대급부로 느린 디스크의 기록 작업이 끝날 때까지 기다려야 하므로 프로그램의 수행 속도가 그만큼 늦어지게 된다.
이제 여기서 ZFS SLOG가 그 기능을 발휘한다. POSIX 규격에 따르면 동기 쓰기는 비휘발성의 안정한 디스크에 그 내역이 기록되기만 하면 그 조건을 만족한다. 그래서 ZFS는 SLOG가 제공되면 동기 쓰기로 주어진 내용을 먼저 SLOG에 기록한다. SLOG는 비휘발성 메모리이므로 동기 쓰기의 조건이 충족되고 따라서 느린 하드 디스크까지 기록을 완료할 필요가 없다. 프로그램은 다음 명령을 계속 수행하고 SLOG에 기록된 데이터 변경 사항은 이후 하드 디스크에 반영된다. 즉, 동기 쓰기가 비동기 쓰기처럼 동작하게 되는 것이다.
당연한 말이지만 이 때 SLOG로 쓸 매체는 하드 디스크보다 빠른 SSD가 권장된다. 또한 별도의 매체가 전용 쓰기 캐시로 할당되므로 입출력을 분산된다. 그리고 SLOG를 쓰게 될 경우 ZFS의 디스크 파편화를 줄이는 효과도 있다. 단, SLOG 장비가 만일 고장날 경우, v19 혹은 그 이전의 zpool의 경우 그 zpool 전체가 소실되는 단점이 있었고 SLOG로 할당하는 장비를 미러링으로 묶어 SLOG 장비의 고장에 대비하는 방법을 썼다. 그 이후 버전의 zpool에서는 이 단점은 사라졌다. 단지 SLOG 장비가 소실되면 SLOG 장비가 제공하던 성능 향상만이 사라질 뿐이다. 그래도 여전히 SLOG 장비 미러링은 성능 유지를 위해 유효한 전략이다.
여기서 vdev의 구성 요소로 다른 vdev가 들어갈 수 있다. 예를 들어 RAID 10와 같은 구성을 위해서는 mirror 2개로 구성된 stripe를 만들면 된다.또한 ZFS는 파일 시스템 자체에서 RAID를 지원하기 때문에, 몇 가지 특징을 보인다.
- Resilvering 시간 감소
RAID의 리실버링(구성 디스크 등을 교체/혹은 일시적인 분리 후 재결합 등의 작업 후, 변동사항이 있었던 디스크의 데이터를 정상 상태로 복원시켜 RAID 구성을 정상 상태로 되돌리는 작업) 등을 할 때 원래 데이터가 적게 들어 있을 경우 시간이 훨씬 줄어들게 된다. 기존의 RAID 솔루션들은 파일 시스템과 분리되어 있기 때문에, 블록 단위까지만을 관리하며 따라서 그 블록 내의 데이터가 어떤 방식으로 기록되는지는 전혀 모르므로 어떤 블록에 데이터가 기록되어 있는지 아닌지를 알수 없다. 그래서 리실버링 작업을 하게 되면 디스크의 처음부터 끝까지를 모두 다 검사하여 복원해야 하므로 몹시 시간이 오래 걸린다. 그러나 ZFS는 그 자체가 곧 파일 시스템이므로 정확하게 어느 부분만 리실버링 작업이 필요한지 알 수 있으며 따라서 리실버링의 작업 시간이 획기적으로 줄어든다.
예를 들어 zpool을 구성하고 있던 데이터 디스크 하나가 케이블의 문제로 잠시 분리되었다가 정비 후 다시 연결된 경우, 그 잠깐의 분리 작업간에 발생한 변동 사항에 대해서만 리실버링을 할 수 있어 단 몇 분만에 리실버링이 끝난다. 그러나 다른 RAID의 경우 이 때 디스크의 시작부터 끝까지 모두 훑어내리는 수 밖에 없어 엄청난 시간이 소요된다.
또한 용량이 10% 정도만 차 있는 RAID의 경우 기존의 RAID 솔루션은 역시 디스크의 처음부터 끝까지 쭉 구별없이 모든 블록을 작업해야 하지만, ZFS의 경우 기록된 데이터가 기록된 10%의 블록에 대해서만 작업을 하므로 작업 시간이 1/10로 줄어든다.
4. zpool
zpool은 기존의 파일 시스템과 컨셉 자체가 꽤 다르며 NTFS나 HFS 등의 기존 파일 시스템의 파티션과 볼륨 사이에 놓인 레이어 계층이다. 다만 ZFS 볼륨이라고도 불리기도 하지만 여기서는 zpool로 통일해서 언급한다. 먼저 ZFS는 각 하드 디스크에서 사용할 GPT 파티션들을 구성원으로 가상 하드웨어인 vdev들을 만든다. 그리고 이 vdev들을 원하는 것끼리 다시 묶은 것이 zpool이다. 이러한 구조를 통해 ZFS는 별도의 RAID 컨트롤러가 없이도 소프트웨어 RAID를 파일 시스템 자체에서 직접 안정적으로 정의할 수 있다. 예를 들어 하나의 zpool은 HDD 6개가 묶인 vdev인 raidz2 + SLOG 장비로 SSD 2개가 미러링으로 묶인 mirror로 구성될 수 있다. 이렇게 구성된 zpool은 각 구성 디스크가 꽂힌 포트가 바뀌어도 정상적으로 각 디스크를 식별해 zpool을 유지하며 다른 컴퓨터로도 손쉽게 zpool을 옮길 수 있다.RAID 모드로는 stripe, mirror, raidz, raidz2 등을 지원하는데 RAID로 따지자면, 각각 raid0, raid1, raid5, raid6와 동일하다. 그런데 이뿐만 아니라 zpool의 구성원으로 디스크를 SLOG(흔히 ZIL로도 불림), L2ARC를 추가할 수 있다.
5. dataset
이 dataset이 바로 일반적인 파일 시스템의 볼륨에 대응되는 부분이다. 그러나 dataset은 우리가 흔히 아는 볼륨과는 확연히 다르다. 먼저 dataset은 우리가 흔히 아는 파티션과 달리 물리적인 특정한 공간에 고정되지 않는다는 점이다. 먼저, 컴퓨터의 파일 시스템은 하드 디스크가 실제로 어떻게 생겼는지(플래터가 몇 장인지, 모터가 몇 개인지 등등...)는 모르며, 단지 첫번째 블록부터 n 블록이 일렬로 늘어서 구성된, 1차원적인 공간으로 인식한다는 점부터 알아야 한다. 그리고 하드 디스크의 파티션은 정확하게 a번째 블록~b번째 블록까지의 하나의 구간이란 형태로 지정한다. 그래서 이 파티션들은 이 1차원적인 공간에서의 특정 구간에 정확하게 1:1 대응되는 구조이며, 또한 각 NTFS, FAT, exFAT 등의 볼륨은 각 파티션에 정확하게 1:1 대응한다. 이로 인해 우리가 흔히 쓰는 Microsoft Windows 등의 운영체제에서는 디스크 볼륨을 확장해야 할 일이 있을 때 만일 그 볼륨이 위치한 파티션의 여유 공간이 만일 없다면 반드시 먼저 어떤 파티션이 끝나는 지점으로부터 늘려야 할 공간만큼의 구간이 텅 비었는지 확인하고, 비지 않았다면 그 곳의 데이터를 딴 곳으로 이동시키는 작업이 반드시 필요하다. 그리고 위의 1:1 대응되는 구조로 인해 파티션의 구간을 그 시작 지점에서부터 앞으로 확장시키는 것은 외부 프로그램을 동원하지 않는 이상 불가능하다.그러나 ZFS는 전혀 구조가 다른데, zpool 안에 여러 개의 dataset이 존재하게 된다. dataset은 마치 파일 디렉토리와 비슷하게 또 다른 dataset 안에 위치할 수도, 그렇지 않을 수도 있다. 기존의 파일 시스템이라면 전혀 꿈도 꿀 수 없는 구조인 것이다. 그리고 위에서 말한대로 물리적인 위치에 붙박히지 않은 특징 때문에 크기의 조절이 매우 자유롭다. dataset의 용량을 늘이는 것도 줄이는 것도(물론 dataset 내의 여유 용량만큼만) 명령을 주는 거의 즉시 바로 완료된다.
그리고 dataset은 스냅샷 기능을 지원한다. 스냅샷이란 어떤 dataset의 어떤 시점에서의 정적 상태를 기억해두는 기능으로, 원한다면 언제든지 그 스냅샷의 상태로 특정 dataset을 복원시킬 수 있는 기능이다. 그리고 이 기능은 몹시 빠르게 가볍게 동작하여 스냅샷을 저장할 때나 특정 스냅샷으로 복원할 때나 거의 명령을 내리는 순간 작업이 완료된다. 거기다가 dataset 전체의 상태를 저장했는데도 스냅샷 직후에는 용량도 몇백 바이트 정도밖에 먹지 않는다. 이는 ZFS가 dataset에서 Copy-on-Write라는 기록 방법을 쓰기 때문에 가능한 일이다. 특정 dataset의 스냅샷을 저장할 경우 그 dataset의 그 스냅샷 이후에 일어나는 파일의 삭제, 변경 등의 수정 작업으로 발생한 변경 부분은 그 데이터의 원본에 덮어써지지 않고 다른 곳에 기록된다. 그리고 현재 시점의 그 dataset을 읽을 때는 변경되지 않은 부분은 원본 부분을 그대로 읽어내고, 그 변경 지점을 읽을 때만큼은 그 다른 곳에 기록된 사본을 참조하는 식이다. 이렇게 한다면 스냅샷을 저장한 이후 추가로 발생하는 용량 소모는 변경된 부분의 용량만큼만 될 뿐, 일일이 dataset 전체의 크기만큼의 사본이 생성될 필요가 없어진다. 물론 복원할 때도 간단하다. 특정 시점으로 복원할 때, 그 특정 시점 이후에 발생한 모든 변경 사항 부분만 삭제해 버리면 바로 원본으로 복원되는 것이다. 그리고 스냅샷 기능은 일정 주기에 맞춰 자동으로 스냅샷을 저장하는 기능도 있으며, 이를 이용하면 주기적으로 각 dataset의 상태를 저장한 뒤 문제가 생기면 바로 복원해 해결할 수 있다. 예를 들어 중요한 자료가 담긴 documents란 이름의 dataset을 5분 단위로 스냅샷을 찍게 한 뒤 자신이 실수로 문서를 삭제해버리는 상황이 발생해도 단 5분의 작업량만큼의 손실을 보는 것으로 끝내버릴 수도 있다. 또는 네트워크 상으로 공유해뒀던 파일 또는 디렉토리가 CryptoLocker 등의 랜섬웨어에 당했더라도 이 스냅샷 기능을 이용한다면 랜섬웨어의 조작이 가해지기 바로 이전의 스냅샷 시점으로 바로 복원해 아무 일도 없었던 것처럼 만드는 것도 가능하다.
그 외에도 dataset에서는 실시간 데이터 압축 기법도 제공된다. 먼저 흔히 우리가 아는 그 파일 압축 기법이 있다. 압축 방법으론 gzip, lz4 등이 있다. 실제로 데이터를 기록할 때 압축을 한 차례 거친 후 기록하는 방식이다. 그런데 이 것 말고도 ZFS에서 지원하는 또 다른 압축 기법으로 deduplication이란 기법이 있다. 이 deduplication이란, 만일 동일한 내용을 가진 블록이 여럿 존재한다면 실제로는 그 블록들 중 하나만을 남기고 나머지는 다 지운 뒤, 그 데이터를 읽을 때는 모두 그 블록을 참조하도록 기록해두는 기법이다. 이 때 블록의 동일성 여부를 검증하기 위해 암호학적으로 안전한 해시 알고리즘으로 그 체크섬을 비교하는 방식을 쓰며 만일 사용자가 원한다면 훨씬 간단하고 빠르지만 안전하지 않은 해시 알고리즘으로 1차 대조를 한 뒤 체크섬이 같다면 그 같은 블록간 1:1 비교를 해보는 옵션도 제공한다. 다만 이 deduplication은 충분한 하드웨어 사양이 보장되어야만 성능의 큰 저하가 발생하지 않으므로 조심스레 쓰는 것이 권장된다.
6. zvol
ZFS는 dataset 말고도 zvol이라는 영역을 설정할 수 있다. dataset이 ZFS가 파일 레벨까지 관리하는 영역이라면, zvol은 그와 달리 ZFS가 블록 단위까지만 관리하는 영역이다. 이것이 의미하는 바는 곧 이 영역의 블록 내용이 어떤 형식으로 짜이든 상관없다는 뜻으로 zvol 영역은 NTFS이나 HFS+ 볼륨 등으로 포맷해서 관리할 수 있다. 물론 ZFS 자체는 전혀 NTFS 볼륨을 전혀 이해하지 못하며, 따라서 보통 이 영역은 iSCSI를 통해 원격으로 다른 컴퓨터에 연결, 탑재되어 물리적으로 연결된 하드 디스크처럼 사용된다.그리고 이러한 특성으로 인해 zvol은 dataset과는 달리 ZFS의 강점 중 하나인 스냅샷 기능이 지원되지 않는다. 그 외엔 zvol은 dataset의 특징을 모두 가지고 있다. 예를 들어 zvol 또한 정확하게 디스크의 특정 구간에 1:1 대응되는 영역이 아니므로, zvol 내의 데이터나 zpool의 용량이 허용하는 한 크기의 변화가 자유자재로 이루어질 수 있다.
7. scrub
ZFS의 강점 중 하나는 Silent Corruption을 방지하는 기능이 있다는 점이다. 디스크에 기록된 데이터는 가만히 두더라도 자연 방사능 등의 영향으로 인해 비트가 뒤집히는 현상이 발생할 수 있다. 이런 데이터 변질은 그 발생 여부를 바로 검출할 수 없다는 점에서 위험하다. 또한 하드 디스크의 비트 당 변질 발생률은 거의 그대로인 반면, 하드 디스크의 용량은 계속 커지고 있기 때문에 이러한 변질의 발생률은 더욱 높아지고 있다. 데이터의 용량이 크면 클 수록 이런 위험성이 높은데, CERN의 연구 결과에 따르면 6개월 넘게 97PB의 데이터를 처리했을 때 그 중 약 128MB의 데이터가 완전히 변질되었다고 한다.ZFS에서는 scrub 명령을 제공하는데, 이 명령은 디스크의 모든 메타데이터와 데이터의 체크섬을 검사해 혹시나 발생했을 변질을 감지한다. raidz, raidz2, mirror 등 redundancy를 제공하는 vdev에서는 scrub으로 Silent Corruption이 감지되면 단순 감지로 끝나지 않고 자체적으로 잘못된 데이터를 정정한다. scrub은 여타 디스크 검사 도구와 달리 검사 대상인 파일 시스템을 오프라인으로 만들 필요가 없이 동작 중인 상태 그대로 검사를 진행할 수 있다. 다만 이 scrub 명령은 말 그대로 모든 데이터를 점검하기 때문에 꽤 많은 시간을 잡아먹는다. 오라클에서는 기업용 드라이브의 경우 최소 1달에 한 번, 일반 드라이브의 경우 최소 1주에 한 번씩 scrub을 진행하는 것을 권장한다.
scrub 명령은 빠른 256비트 알고리즘인 fletcher4를 써서 체크섬을 검사한다. 물론 SHA-256 알고리즘을 쓰도록 지정할 수 있지만, fletcher4보단 속도가 느림을 주의해야 한다. 물론 해시 함수의 특성 상 체크섬 검사가 틀릴 확률은 있다. 단, 2^256회의 검사중 한 번. 이를 소수로 표현하면 0.00000000000000000000000000000000000000000000000000000000000000000000000000001%이다. 참고로 시장에서 가장 신뢰성 높은 Non-ECC RAM 기준으로, 메모리 에러 발생률은 저것보다 50배 더 빈도가 높다. 그 정도로 몹시 낮은 확률이므로 안심하자.
8. 단점
ZFS는 위에서 보았듯 현존하는 파일 시스템의 최종 보스라고 볼 수 있는 존재지만, 그렇다고 해서 장점만이 존재하는 것은 아니다.8.1. 서버용 장비 권장
ZFS의 특성상 Raidz의 연산이나 ZFS의 여러 기제들이 전용 칩이 아닌 CPU에 의존하고 있어서 성능을 올리기가 쉽지 않은데, 이걸 해결하려면 강력한 CPU와 많은 메모리, SSD 따위를 추가로 필요로 한다. 이는 여분의 장비로 NAS를 만들고자 하는 사람들에게 문제가 된다. 여분의 장비를 이용해 싼 값으로 NAS를 구성하고자 하는데, 강력하고 새로운 CPU나 ECC 메모리, ECC 지원 보드를 사야 한다면 원래 취지에 완전히 반하는 일이 되고 마는 것이다. 물론 이런 장비를 여분으로 가지고 있는 사람이라면 이야기가 좀 다르지만, 그런 사람들이 흔할 리가 있나. 이런 조건은 ZFS를 제대로 써먹어보고자 하는 사람들을 막는 진입 장벽이 된다.8.1.1. 반론
상술했듯 ZFS는 제대로 사용하기 위해선 여러가지 조건이 갖춰져 있어야 하는데사실 이는 엔터프라이즈 환경을 기준했을때의 이야기고 어느정도 타협본다면 ZFS는 특정한 하드웨어를 요구하는 파일시스템이 아니다.
예를들면 강력한 엔터프라이즈 스토리지는
- 다수의 엔터프라이즈급 10k~15k SAS 디스크
- 메모리와 배터리, 전용 연산칩을 가진 SAS Raid Controller 혹은 최소한 디스크 엔클로저를 연결할 HBA
- 티어1급의 NVMe
정도가 기본에 추가로 다수의 사용자와 프로토콜[1]을 처리할 강력한 멀티코어 CPU와 ECC메모리가 필수적인데 ZFS는 저런 비싼 장비를 쓰지 않고 오로지 CPU, 메모리 두가지에 의존적이기 때문에 많은 비용절감이 가능하다.
즉, ZFS는
- 보통 수십만원씩 하는 엔터프라이즈 10k~15k SAS디스크 대신 흔히 보이는 7.2k SATA 디스크
- 보통 수십에서 백만원대까지 찍는 SAS Raid Controller 대신 흔하디 흔한 마더보드의 디스크 컨트롤러와 CPU
- 보통 수십에서 수백만원대까지 찍는 티어1급 NVMe 대신 주메모리와 SATA SSD
형태로 압도적인 비용절감이 가능하며 이런식으로 절약되는 자금을 용량증대 혹은 성능 향상을 위한 더 많은 메모리와 SSD 그리고 더 강력한 CPU 구입에 재투자 하거나 그리 부하가 크지 않고, 성능도 이런 저런 이유로 많이 요구하지 않는다면[2] ZFS박스도 거기에 맞춰 충분한 성능이 나오면서 저렴하게 만들어지고 덤으로 다른 파일 시스템보다 나은 데이터 무결성을 챙길 수 있단 소리다.
이런 사실을 두고 보면 ZFS는 결코 하드웨어적인 면에서 서버급의 장비를 필수적으로 요구하는 파일시스템이 아니다.
또한 워크스테이션/서버에서 일반적으로 쓰이는 별도의 하드웨어 Raid 컨트롤러를 사용해 Raid를 구성하는건 권장되지 않는데, 이는 ZFS가 가진 오류 검출/정정 기능과 하드웨어 Raid 컨트롤러가 수행하는 오류검출/정정이 서로 충돌을 일으킬 우려가 있기 때문이다.[3] 물론 이런 권장사항은 유사한 메커니즘을 가진 Btrfs와 Refs도 동일하다.
8.1.2. ECC 메모리 권장?
결론부터 말하자면, ECC가 권장되는 것은 맞지만, 다른 파일시스템에 비해서 특히 더 중요한 것은 아니다.zfs에 ECC 메모리가 필수라는 통설이 퍼진 이유는 'scrub'이라는 기능 때문이다. 저장된 데이터의 손상[4]을 감지하여 복구하는 기능인데, 'scrub of death'라는 문제가 제기되었다. scrub을 진행하여 손상을 감지할 때, 메모리가 오작동하는 경우 멀쩡한 데이터를 복구 대상으로 잡아 망가트릴 수 있다는 주장이다.
하지만, 메모리의 비트 하나가 뒤집히는 정도를 넘어, 여러개의 비트가 동시에 뒤집히면서, 해시 대조까지 들어맞아야 데이터가 손상되므로, 비-ECC 메모리로 인한 scrub of death는 확률이 매우 낮다는 분석이 있다.링크 비-ECC 메모리를 사용하는 경우에도 scrub을 실행하는 것이 데이터 무결성에 이득이 된다는 결론이다.
8.2. 높은 RAM 점유율
위에서 언급한 ARC는 분명 ZFS의 강력한 장점이지만 역으로 메모리 사용량이 무지막지하게 늘어난다는 단점이 있다. ARC는 RAM을 점유하며 ARC의 크기는 보통 ZFS에 할당된 하드 디스크 용량의 1/1000 정도 혹은 그 이하가 된다. 1TB당 최소 1GB의 메모리가 필요하다는 속설이 널리 퍼져있다. 간단하게 말해 ZFS에 할당된 하드 디스크 용량이 총 24TB 정도가 된다면 ZFS 전용으로 최소 24GB의 RAM을 갖출 것을 권한다는 뜻이다.8.2.1. 반론
FreeNAS의 개발 주체인 IX systems나 ZFS의 원 개발사인 오라클 등에서는 ZFS는 굳이 그 비율을 맞추지 않아도 자동으로 ARC의 크기를 조절한다고 말하고 있다.1TB당 1GB는 어디까지나 ZFS의 최적의 성능을 뽑아내기 위해서 필요한 권장사항이다. 기가비트 랜 등을 통해서 접속하는 파일 서버에서 ZFS를 사용하고자 하는 경우, 기가비트 전송 능력만 발휘하면 충분하다. 따라서 위의 램 RAM 권장사항을 따르지 않더라도 8GB 정도의 기본적인 RAM 만 갖추면 사용자 5인 이하 수준의 파일서버 용도로는 충분하다. 홈서버 등의 제작을 고려한다면 참고하자.
물론 RAM이 충분히 커서 ARC가 크면 클수록 좋다. 캐시가 커지면 커질수록 캐시 적중률이 오르고, 이렇게 되면 가장 빠른 매체인 RAM 단계에서 데이터의 접근이 끝나고 가장 느린 하드 디스크까지 직접 접근해야 하는 경우가 적어지기 때문이다.
그리고 ZFS의 장점 중 하나인 램디스크 캐싱을 통한 자주 사용하는 데이터들의 접근속도 향상을 포기해도 되는 환경이라면(ex: 어차피 램디스크 캐싱이 의미없는 대용량 영화 파일들을 뭉쳐놓은 개인 서버라던지.), 극단적일 경우 ARC를 아예 안잡아버리는, 그러니까, 캐싱 기능을 강제로 꺼버리는 방법도 있다. 이럴 경우 RAM을 단 1KB도 안 잡아 먹는다. 대신 성능은 exFAT이나 NTFS와 같은 일반적인 파일시스템과 비슷해진다.
8.3. 디스크 단편화로 인한 성능 저하
꽤 오래된 이슈중 하나로 DBMS를 ZFS위에 사용한다거나 하는 경우 단편화로 인한 성능의 급락이 보고되어 있다. 문제는 이걸 해결할 별도의 조각모음 솔루션이라던지, DBMS만을 위한 특별난 동작 모드라던지 이런게 전혀 없다. 워크어라운드로 전체 용량의 1~2할정도는 항상 남겨두란 권고 정도가 전부인 상황.일반적인 파일시스템에서야 별 상관없지만 애초부터 미션 크리티컬을 목표하는게 이런 엔터프라이즈 시장이고 엔터프라이즈 시장을 타겟으로 팔리고 개발되는게 솔라리스와 ZFS인데 이런 심각한 문제가 있는 탓에 DBMS를 올리는 용도론 권장하기 어려운 상황이다.
자세한 내용은 여기 에서 확인하면 된다.
8.4. 파일이름 길이 제한
파일이름을 확장자까지 포함하여 최대 255 bytes 까지만 사용할 수 있는 문제가 있다. 옛날에는 문제가 안되었지만 NTFS나 APFS는 유니코드 기준 255자 또는 그 이상을 지원하는데 비해 ZFS는 여전히 255 바이트 제한으로 한글이나 다른 아시아권 글자를 UTF-8로 사용하면 80~100자 남짓 쓰는 것이 한계다.[5] 흔한 사례를 들자면 조금 긴 제목을 가진 유튜브 영상은 제목 그대로 파일이름을 붙여서 저장하는게 불가능한 수준.이 제한은 파일시스템 위에 DB를 올리거나 VM의 디스크 이미지를 저장하는 서버에서는 크게 문제되지 않지만 소비자가 직접 사용하는 파일시스템에서는 APFS나 exFAT, NTFS에서 문제 없던 파일이름이 ZFS에서는 사용이 불가능하여 자료의 호환성 문제를 일으킬 수 있다. 특히 NTFS로 운용하던 파일서버를 ZFS로 이주하고자 한다면 기존 파일의 이름 길이를 체크하여 문제되는 파일을 전부 변경할 필요가 있다.
9. 현재 이식된 운영 체제
9.1. 솔라리스 계열
9.2. FreeBSD 계열
몇년전부터 OpenZFS를 설치 옵션으로 나뒀지만, FreeBSD 13에서 OpenZFS 소스 트리를 갈아엎으면서 이제는 ZFS가 기본이 되었다.9.3. 리눅스
라이선스 문제로 인하여[6] ZFS 지원이 리눅스 커널 소스에 포함된 적은 없다. 하지만 커널 모듈 및 FUSE 드라이버 형태로는 포팅이 되어 있기 때문에 리눅스에서도 ZFS 사용이 가능하다. 또한, 유사한 기능을 목표로 개발되고 있는 Btrfs가 있어서 미래의 ZFS 대항마로 주목되고 있다.9.3.1. ZFS-on-Linux
홈 페이지리눅스 ZFS 지원용 커널 모듈이다. 오랫동안 안정화 등에 개발 역량을 집중하고 있었으나, 문제가 어느 정도 해결되었는지 zpool 버전을 v5000 으로 올리는 등 기능 확장에도 신경쓰고 있다.
9.3.2. 우분투
16.04 LTS 버전부터 ZFS가 설치 시점부터 지원된다. 단, 커널에 직접 ZFS 지원을 집어넣은 것은 아니고, 커널 모듈을 기본 설치 옵션에 포함시킨 것으로 보인다. 다만 이를 기본으로 지원하는 것이 라이선스 위반인지 아닌지에 대해서 이견이 존재하는 상황이다.우분투 ZFS 지원 발표 링크
라이선스 이슈 관련 링크
9.4. macOS(무산됨)
취소선으로 되어있지만 사실 처음에는 애플이 HFS를 대신할 파일 시스템으로 ZFS를 사용하려고 했었다. 이를 위해 썬 마이크로시스템즈과 협상하여 iCloud에 썬의 장비를 사용하는 조건으로 라이선스 합의를 이루어냈으나 썬이 오라클에 인수된 이후 2010년에 합의가 결렬되면서 ZFS 도입은 무산되었다. 이후 애플은 ZFS 대신 APFS을 독자적으로 개발하여 그걸로 대체했다.참고로는 2006년부터 포팅을 진행했으며 2007년에 썬 마이크로시스템즈 CEO는 ZFS가 Mac OS X에서 지원할 예정이라고 미리 밝히기도 했다. 하지만 오라클에 인수되고 결렬되면서 없던 일이 되었다.
10. ZFS를 사용 하는 솔루션
10.1. TrueNAS
홈 파일서버를 쉽게 구축하는 것을 목표로 하는 공개형 NAS 운영 체제. FreeBSD 기반이다. 그래서 FreeNAS 라는 이름이었지만, 2020년 이후로 TrueNAS 로 이름이 바뀌었으며, 리눅스 기반의 TrueNAS Scale도 출시되었다. 다양한 플러그인을 통하여 복합 가정용 서버 운영 체제로 사용할 수 있는 잠재력을 갖추고 있다.과거에는 ZFS 버전이 v5000 이라는 독자 버전을 사용했기 때문에 FreeNAS에서 만든 zpool 을 다른 곳에서 마운트하는 것이 까다로웠다. 하지만, 다른 곳에서 만든 zpool 을 FreeNAS에서 마운트하는 것은 가능했다.
현재는 FreeBSD, ZFS-on-Linux 등 다른 ZFS도 v5000 를 사용하게 되어서 호환성 문제는 많이 해결되었다.
10.2. XigmaNAS
FreeNAS의 포크 버전.포크버전이라고는 하나, 포크 된 지 시간이 많이 흘러서 현재는 특색이 많이 달라진 상태이다.
FreeNAS와 비교하면 파일 서버로서의 기능에 주로 집중한다.
10.3. Nexenta
미국 캘리포니아의 Nexenta라는 스타트업에서 제공하는 ZFS 서비스로, NexentaStor라는 프로그램을 통해 ZFS에 대한 관리를 Web GUI를 통해 가능하게 한다. 라이선스는 대부분 기업용으로 제공되지만, 학생의 경우 학교 이메일을 통해 30일 무료 Trial을 받을 수 있고 이를 Ubuntu등 기타 VM에 설치하여 사용할 수 있다. ZFS의 zpool이나 캐시, 로그, hot spare등의 많은 기능을 제공하므로 ZFS를 보다 더 쉽게 이해하기에는 꽤나 제격인 프로그램이다.10.4. CodexOS
영국의 영상시스템 제작 회사인 Codex사는 ARRI 카메라에 사용되는 메모리카드부터, NAS 시스템까지 모두 ZFS를 사용하고 있다. 특히 MediaVault 시스템은 3종류 모두 ZFS를 사용하고 있는데, 제품명은 D1200, R1200, R3600이다. 기반이 되는 OS는 CodexOS라는 직접 개발한 운영체계를 사용하고 있다. 가격이 방송시스템중 하늘을 날아갈 정도로 고가이지만, 헐리우드나 일본, 영국, 프랑스등에서 표준데이터장비로 사용하고 있다. 고가인만큼 제품의 안정성과 데이터의 보관능력은 타의 추종을 불허하는 편이다. D1200은 ZFS를 채용한 시스템중 유일하게 휴대용 제품이다.10.5. Proxmox
데비안을 기반[7]으로하는 오픈소스 하이퍼바이저 OS인 Proxmox도 ZFS를 활용한다.기본적으로 GUI ZFS Tool을 제공하며, 당연히(?) CLI기반으로도 관리가 가능하다.10.5.1. OMV
역시 마찬가지로 데비안을 기반으로 하는 NAS용 OS인 OMV또한 OMV-Extra 확장을 설치하면 ZFS를 이용할 수 있다. 왜 Proxmox하단으로 두었냐 하면, OMV 5까지는 Proxmox Kernel을 이용하여 ZFS를 지원했기 때문. 6부터는 자체적으로 지원하나, 데비안 업데이트에 맞춰 ZFS플러그인이 바로바로 업데이트 되지 않아 불안정한 모습을 보여, OMV6에서도 Proxmox커널을 설치하는 방법이 권장된다[8]11. 참고 링크
[1] 가정에서 많이 쓰이는 윈도 폴더공유/사내에서 AD를 통해 흔하게 쓰이는 CIFS의 경우 상당히 강력한 CPU를 요구한다[2] 일반적인 가정내 환경에선 스위치/라우터/ap 성능 한계상 내부망자체가 1기가빗 혹은 수백 메가빗 환경이며, 외부망은 당연히 잘나봐야 1기가빗 환경이다. 엔터프라이즈 환경처럼 수십 기가빗 FC망이거나 lacp로 회선 묶어쓰는 환경이 아니다[3] http://open-zfs.org/wiki/Hardware[4] 저장장치를 사용하지 않고 가만히 놔둬도 소량의 비트가 자연 방사선이나 기타 물리적 요인에 의해 변조될 수 있다.[5] UTF-8을 사용할 경우 글자당 1~4바이트까지 가변이기 때문에 상황에 따라 글자 수 기준 사용 가능한 최대 파일이름 길이가 달라진다.[6] 원래 공개되었던 OpenZFS 의 라이선스는 CDDL v1.0 이며, 이는 리눅스 커널의 라이선스인 GPL v2와 상호 호환되지 않는다. 즉 현재로서는 리눅스 커널에 ZFS 소스 코드를 삽입한 결과물을 합법적으로 배포할 방법이 없다.[7] 단, 커널은 Ubuntu을 베이스로 한 커스텀 커널을 이용한다. 따라서 ZFS지원은 데비안이 담당하지 않는 것이 특이한 부분.[8] 이역시 마찬가지로 OMV-Extra를 설치하여 Proxmox커널을 설정할 수 있다.