ZFS

썬마이크로시스템즈에서 개발하였고, 솔라리스에 탑재되었다. 지상 최강의 파일 시스템 이라고 일컬어지기도 한다.
다음과 같은 기능들을 지원하기 때문.

단점으로 캐시인 arc를 주요하게 쓸경우 메모리 사용량이 엄청나게 높아진다. 하지만 덕분에 자잘하게 쓰기를 할 경우나 읽기를 할 경우에는 말도 안 되는 속도가 나오기도 한다. 예를 들어 SmartOS 에서 KVM에 올린 가상머신에서 랜덤 읽기/쓰기의 디스크 IO 속도가 1GB/s 이상 나오는 경우가 보이기도 한다. 물론 메모리는 가능한 한 다 땡겨 쓰기에 일어 나는 일이다.

Adaptive Replacement Cache의 약어로 최근에 읽거나 쓴 파일들이 1차적으로 위치하는 저장공간이다. cache로서 ZFS가 메모리를 엄청나게 쓰는 주요 원인이 이 ARC이다.
ZFS는 ARC의 내용물을 단순히 최근에 읽거나 썼다, 접근 횟수가 많다 뿐만 아니라 hit ratio에 따라 내용물을 스스로 조절하는 메커니즘을 가지고 있다.
기본적으로 램디스크로 주 메모리를 잡아 사용하기 때문에 휘발성이며, 매우 빠르고 기가당 비용상 결코 저렴한 저장소가 아니기 때문에 크기가 한정적이 될수밖에 없다.
이런 hit ratio와 용량의 한계를 극복하기 위한 2차 cache가 후술될 L2ARC다.

vdev는 Virtual Device(가상 장치)의 약어지만 꼭 가상 장치를 뜻하는 것은 아니다. vdev는 zpool을 구성하는 요소로서 zpool과 물리적인 디스크 사이에 존재하는 하나의 추상화된 계층이다. 예를 들어 흔히 우리가 아는 RAID로 형성된 가상 장치 등이 여기에 대응된다. 소프트웨어 RAID와 관련된 ZFS의 vdev에는 다음과 같은 종류들이 있다.

여기서 vdev의 구성 요소로 다른 vdev가 들어갈 수 있다. 예를 들어 RAID 10와 같은 구성을 위해서는 mirror 2개로 구성된 stripe를 만들면 된다.또한 ZFS는 파일 시스템 자체에서 RAID를 지원하기 때문에, 몇 가지 특징을 보인다.

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를 추가할 수 있다.

이 dataset이 바로 일반적인 파일 시스템의 볼륨에 대응되는 부분이다. 그러나 dataset은 우리가 흔히 아는 볼륨과는 확연히 다르다. 먼저 dataset은 우리가 흔히 아는 파티션과 달리 물리적인 특정한 공간에 고정되지 않는다는 점이다. 먼저, 컴퓨터의 파일 시스템은 하드 디스크가 실제로 어떻게 생겼는지(플래터가 몇 장인지, 모터가 몇 개인지 등등...)는 모르며, 단지 첫번째 블록부터 n 블록이 일렬로 늘어서 구성된, 1차원적인 공간으로 인식한다는 점부터 알아야 한다. 그리고 하드 디스크의 파티션은 정확하게 a번째 블록~b번째 블록까지의 하나의 구간이란 형태로 지정한다. 그래서 이 파티션들은 이 1차원적인 공간에서의 특정 구간에 정확하게 1:1 대응되는 구조이며, 또한 각 NTFS, FAT, exFAT 등의 볼륨은 각 파티션에 정확하게 1:1 대응한다. 이로 인해 우리가 흔히 쓰는 Microsoft Windows 등의 OS에서는 디스크 볼륨을 확장해야 할 일이 있을 때 만일 그 볼륨이 위치한 파티션의 여유 공간이 만일 없다면 반드시 먼저 어떤 파티션이 끝나는 지점으로부터 늘려야 할 공간만큼의 구간이 텅 비었는지 확인하고, 비지 않았다면 그 곳의 데이터를 딴 곳으로 이동시키는 작업이 반드시 필요하다. 그리고 위의 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은 충분한 하드웨어 사양이 보장되어야만 성능의 큰 저하가 발생하지 않으므로 조심스레 쓰는 것이 권장된다.

ZFS는 dataset 말고도 zvol이라는 영역을 설정할 수 있다. dataset이 ZFS가 파일 레벨까지 관리하는 영역이라면, zvol은 그와 달리 ZFS가 블록 단위까지만 관리하는 영역이다. 이것이 의미하는 바는 곧 이 영역의 블록 내용이 어떤 형식으로 짜이든 상관없다는 뜻으로 zvol 영역은 NTFS이나 HFS+ 볼륨 등으로 포맷해서 관리할 수 있다. 물론 ZFS 자체는 전혀 NTFS 볼륨을 전혀 이해하지 못하며, 따라서 보통 이 영역은 iSCSI를 통해 원격으로 다른 컴퓨터에 연결, 탑재되어 물리적으로 연결된 하드 디스크처럼 사용된다.

그리고 이러한 특성으로 인해 zvol은 dataset과는 달리 ZFS의 강점 중 하나인 스냅샷 기능이 지원되지 않는다. 그 외엔 zvol은 dataset의 특징을 모두 가지고 있다. 예를 들어 zvol 또한 정확하게 디스크의 특정 구간에 1:1 대응되는 영역이 아니므로, zvol 내의 데이터나 zpool의 용량이 허용하는 한 크기의 변화가 자유자재로 이루어질 수 있다.

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배 더 빈도가 높다. 그 정도로 몹시 낮은 확률이므로 안심하자.

ZFS는 위에서 보았듯 현존하는 파일 시스템의 최종 보스라고 볼 수 있는 존재지만, 그렇다고 해서 장점만이 존재하는 것은 아니다.

이전엔 ECC 메모리를 권장한다는 항목이 있었으나, 실제로는 ZFS 자체는 ECC를 딱히 필수적으로 요구하지는 않는다.
메모리 상의 비트 플립에 의한 데이터 오염과 scrub 작업에서 생기는 비트 플립으로 인한 'scrub of death' 같은 것이 문제가 된다고 명시되어 있었는데, 이는 사실이 아닌 것으로 보인다.[1] 아닌게 아니라 상식적인 수준에서도 'scrub of death' 시나리오 이외의 대부분의 경우는 ZFS든 아니든 ECC 메모리가 아니면 모두 문제가 있는 시나리오임을 알 수 있다.

하지만, ZFS를 쓰는 목적이 보통은 데이터의 무결성(data integrity) 유지임을 생각하면, ZFS가 ECC를 요구하는 것이 아니라, 사용 목적상 서버에 ECC가 요구되는 것은 맞다.

또한 ZFS의 특성상 Raidz의 연산이나 ZFS의 여러 기제들이 전용 칩이 아닌 CPU에 의존하고 있어서 퍼포먼스를 올리기가 쉽지 않은데, 이걸 해결하려면 강력한 CPU와 많은 메모리, SSD 따위를 추가로 필요로 한다. 이는 여분의 장비로 NAS를 만들고자 하는 사람들에게 문제가 된다. 여분의 장비를 이용해 싼 값으로 NAS를 구성하고자 하는데, 강력하고 새로운 CPU나 ECC 메모리, ECC 지원 보드를 사야 한다면 원래 취지에 완전히 반하는 일이 되고 마는 것이다. 물론 이런 장비를 여분으로 가지고 있는 사람이라면 이야기가 좀 다르지만, 그런 사람들이 흔할 리가 있나. 이런 조건은 ZFS를 제대로 써먹어보고자 하는 사람들을 막는 진입 장벽이 된다.

상술했듯 ZFS는 제대로 사용하기 위해선 여러가지 조건이 갖춰져 있어야 하는데
사실 이는 엔터프라이즈 환경을 기준했을때의 이야기고 어느정도 타협본다면 ZFS는 특정한 하드웨어를 요구하는 파일시스템이 아니다.

예를들면 강력한 엔터프라이즈 스토리지는

정도가 기본에 추가로 다수의 사용자와 프로토콜[2]을 처리할 강력한 멀티코어 CPU와 ECC메모리가 필수적인데 ZFS는 저런 비싼 장비를 쓰지 않고 오로지 CPU, 메모리 두가지에 의존적이기 때문에 많은 비용절감이 가능하다.

즉, ZFS는

형태로 압도적인 비용절감이 가능하며 이런식으로 절약되는 자금을 용량증대 혹은 퍼포먼스 향상을 위한 더 많은 메모리와 SSD 그리고 더 강력한 CPU 구입에 재투자 하거나 그리 부하가 크지 않고, 성능도 이런 저런 이유로 많이 요구하지 않는다면[3] ZFS박스도 거기에 맞춰 충분한 성능이 나오면서 저렴하게 만들어지고 덤으로 다른 파일 시스템보다 나은 데이터 무결성을 챙길 수 있단 소리다.
이런 사실을 두고 보면 ZFS는 결코 하드웨어적인 면에서 서버급의 장비를 필수적으로 요구하는 파일시스템이 아니다.

또한 워크스테이션/서버에서 일반적으로 쓰이는 별도의 하드웨어 Raid 컨트롤러를 사용해 Raid를 구성하는건 권장되지 않는데, 이는 ZFS가 가진 오류 검출/정정 기능과 하드웨어 Raid 컨트롤러가 수행하는 오류검출/정정이 서로 충돌을 일으킬 우려가 있기 때문이다.[4] 물론 이런 권장사항은 유사한 메커니즘을 가진 Btrfs와 Refs도 동일하다.

위에서 언급한 ARC는 분명 ZFS의 강력한 장점이지만 역으로 ZFS의 약점으로도 작용하는 양날의 검이다. ARC는 RAM을 점유하며 ARC의 크기는 보통 ZFS에 할당된 하드 디스크 용량의 1/1000 정도 혹은 그 이하가 된다. FreeNAS의 개발 주체인 IX systems나 ZFS의 원 개발사인 오라클 등에서는 ZFS는 굳이 그 비율을 맞추지 않아도 자동으로 ARC의 크기를 조절한다고 말하고 있다. 다만 커뮤니티 등지에서의 속설 상으로는 최적의 성능 보장을 위해서는 1TB당 무려 최소 1GB의 RAM의 비율을 맞출 것을 요구한다. 간단하게 말해 ZFS에 할당된 하드 디스크 용량이 총 24TB 정도가 된다면 ZFS 전용으로 최소 24GB의 RAM을 갖출 것을 권한다는 뜻이다. 물론 RAM이 충분히 커서 ARC가 크면 클수록 좋다. 캐시가 커지면 커질수록 캐시 적중률이 오르고, 이렇게 되면 가장 빠른 매체인 RAM 단계에서 데이터의 접근이 끝나고 가장 느린 하드 디스크까지 직접 접근해야 하는 경우가 적어지기 때문이다.

단, 이것은 어디까지나 ZFS의 최적의 성능을 뽑아내기 위해서 필요한 권장사항이다. 기가비트 랜 등을 통해서 접속하는 파일 서버에서 ZFS를 사용하고자 하는 경우, 기가비트 전송 능력만 발휘하면 충분하다. 따라서 위의 램 RAM 권장사항을 따르지 않더라도 8GB 정도의 기본적인 RAM 만 갖추면 사용자 5인 이하 수준의 파일서버 용도로는 충분하다. 홈서버 등의 제작을 고려하는 위키러는 참고하자.

그리고 ZFS의 장점 중 하나인 램디스크 캐싱을 통한 자주 사용하는 데이터들의 접근속도 향상을 포기해도 되는 환경이라면(ex: 어차피 램디스크 캐싱이 의미없는 대용량 영화 파일들을 뭉쳐놓은 개인 서버라던지.), 극단적일 경우 ARC를 아예 안잡아버리는, 그러니까, 캐싱 기능을 강제로 꺼버리는 방법도 있다. 이럴 경우 RAM을 단 1KB도 안 잡아 먹는다. 대신 성능은 exFAT이나 NTFS와 같은 일반적인 파일시스템과 비슷해진다. 물론 이러면 굳이 ZFS를 쓸 당위성은 줄어들지만, zpool 개념이라든지 등에서 비롯되는 다른 장점도 있으니, 이부분은 어디까지나 개인의 니즈에 맞게 설정하기 나름이다.

꽤 오래된 이슈중 하나로 DBMS를 ZFS위에 사용한다거나 하는 경우 단편화로 인한 퍼포먼스의 급락이 보고되어 있다.
문제는 이걸 해결할 별도의 조각모음 솔루션이라던지, DBMS만을 위한 특별난 동작 모드라던지 이런게 전혀 없다.
워크어라운드로 전체 용량의 1~2할정도는 항상 남겨두란 권고 정도가 전부인 상황.

일반적인 파일시스템에서야 별 상관없지만 애초부터 미션 크리티컬을 목표하는게 이런 엔터프라이즈 시장이고 엔터프라이즈 시장을 타겟으로 팔리고 개발되는게 솔라리스와 ZFS인데 이런 심각한 문제가 있는 탓에 DBMS를 올리는 용도론 권장하기 어려운 상황.

자세한 내용은 여기 에서 확인하면 된다.

라이센스 문제로 인하여[5] ZFS 지원이 리눅스 커널 소스에 포함된 적은 없다. 하지만 커널 모듈 및 FUSE 드라이버 형태로는 포팅이 되어 있기 때문에 리눅스에서도 ZFS 사용이 가능하다. 또한, 유사한 기능을 목표로 개발되고 있는 Btrfs가 있어서 미래의 ZFS 대항마로 주목되고 있다.

홈 페이지
리눅스 ZFS 지원용 커널 모듈이다. 오랫동안 안정화 등에 개발 역량을 집중하고 있었으나, 문제가 어느 정도 해결되었는지 zpool 버전을 v5000 으로 올리는 등 기능 확장에도 신경쓰고 있다.

16.04 LTS 버전부터 ZFS 가 설치 시점부터 지원된다. 단, 커널에 직접 ZFS 지원을 집어넣은 것은 아니고, 커널 모듈을 기본 설치 옵션에 포함시킨 것으로 보인다. 다만 이를 기본으로 지원하는 것이 라이센스 위반인지 아닌지에 대해서 이견이 존재하는 상황이다.
우분투 ZFS 지원 발표 링크
라이센스 이슈 관련 링크

홈 파일서버를 쉽게 구축하는 것을 목표로 하는 공개형 NAS 운영체제.
FreeBSD 기반이다.
다양한 플러그인을 통하여 복합 홈 서버 OS로 사용할 수 있는 잠재력을 갖추고 있다.

과거에는 ZFS 버전이 v5000 이라는 독자 버전을 사용했기 때문에 FreeNAS 에서 만든 zpool 을 다른 곳에서 마운트하는 것이 까다로웠다.
단, 다른 곳에서 만든 zpool 을 FreeNAS 에서 마운트하는 것은 가능했다.

현재는 FreeBSD, ZFS-on-Linux 등 다른 ZFS도 v5000 를 사용하게 되어서 호환성 문제는 많이 해결되었다.

FreeNAS 의 포크 버전.
포크버전이라고는 하나, 포크 된 지 시간이 많이 흘러서 현재는 특색이 많이 달라진 상태이다.
FreeNAS 와 비교하면 파일 서버로서의 기능에 주로 집중한다.

미국 캘리포니아의 Nexenta라는 스타트업에서 제공하는 ZFS서비스로, NexentaStor라는 프로그램을 통해 ZFS에 대한 관리를 Web GUI를 통해 가능하게 한다. 라이센스는 대부분 기업용으로 제공되지만, 학생의 경우 학교 이메일을 통해 30일 무료 Trial을 받을 수 있고 이를 Ubuntu등 기타 VM에 설치하여 사용할 수 있다. ZFS의 zpool이나 캐시, 로그, hot spare등의 많은 기능을 제공하므로 ZFS를 보다 더 쉽게 이해하기에는 꽤나 제격인 프로그램이다.