1. ZFS 소개
■ ZFS 역사(History)
ZFS was designed and implemented by a team at Sun led by Jeff Bonwick. It was announced on September 14, 2004. Source code for ZFS was
integrated into the main trunk of Solaris development on October 31, 2005 and released as part of build 27 of OpenSolaris on November
16, 2005. Sun announced that ZFS was included in the 6/06 update to Solaris 10 in June 2006, one year after the opening of the OpenSolaris community.
The name originally stood for “Zettabyte File System”, the original name selectors happened to like the name, and a ZFS file system has
the ability to store 340 quadrillion zettabytes (256 pebi-zebibytes exactly, or 2128 bytes). Every ZiB is 270 bytes.
■ ZFS 소개
ZFS는 간편한 관리성, 트랜젝션 기반의 구문, 완벽한 데이타 무결성 보장, 대용량의 확장성을 제공하는 전혀 새로운 종류의 파일 시스템이다.
ZFS는 기존의 존재하던 기술의 발전이 아니다; 기본적으로 데이타 관리에 대한 새로운 접근이다. 우리는 지난 20년간 지속되온 새로운 개념의 개발,
소스의 복잡성 제거등의 방법들을 모두 날려 버리고 사용이 간편한 새로운 종류의 스토리지 시스템을 만들었다.
ZFS는 스토리지 풀 모델을 제시함으로써 기존의 볼륨과 그에 기반한 파티셔닝, 프로비져닝, 대역폭 낭비, 이전의 불편성등의 문제를 완전히 제거했다.
수천개의 파일시스템이 하나의 일반 스토리지 안에 담겨 질 수 있고 각각의 파일시스템은 오직 실제로 필요한 만큼의 공간만을 사용하게 됐다.
풀의 모든 디바이스들의 대역폭은 항상 모든 파일시스템에서 사용 가능하다. 모든 동작은 copy-on-write 트렌젝션으로 이루어져 있어서 디스크의
상태는 항상 유효 하다. 즉 더이상 fsck(1M)를 ZFS 파일 시스템에 실행할 필요가 없다. 모든 블럭들은 데이타 오류에 대비해 항상 체크섬 되며 replicate 설정
(미러 또는 RAID)에 의해 자동으로 치유가 가능하다. 만약 하나의 카피가 손상을 입었다면 ZFS는 발견 후에 다른 카피를 이용하여 복구 해 준다.
ZFS는 RAID-Z라는 새로운 데이타 replication 모델을 제공한다. RAID-Z는 RAID-5와 비슷하지만 가변 stripe width를 제공함으로써 RAID-5의
write hole(stripe 오류는 데이타와 페리티 비트가 업데이트 될때의 정전으로 발생한다)오류를 제거했다. 모든 RAID-Z는 full-stripe 쓰기 방법을 사용한다.
읽기 -수정-쓰기등의 부가 과정이 필요 없고 write hole 문제도 없으며 가장 중요한 것은 하드웨어에 NVRAM이 있을 필요가 없다는 것이다. ZFS는 저렴한 디스크를 선호한다.
물론 저렴한 디스크는 오류가 생길수 있다. 그러므로 ZFS는 디스크 scrubbing을 제공한다. ECC memory의 scrubbing과 같이 바로 정정이 가능하더라도 모든
데이타를 다시 읽어 들여서 잠재적인 오류를 찾아내게 된다. scrub은 모든 스토리지 풀을 순회 하면서 모든 블럭의 카피들을 읽고 256비트 체크섬을 이용하여
검증 한 후에 복구가 필요 하면 복구를 하게 된다. 이 모든 작업은 스토리지 풀이 온라인인 상태에서 이루어지게 된다. ZFS는 CPU의 파이프라인 개념과 비슷한
I/O 파이프라인 엔진을 가지고 있다. 파이프라인은 I/O 의존성 그래프에 기반하여 스코어보딩, 우선순위, 데드라인 스케줄링, 오류 발생 대처 및 I/O 일괄 처리
등의 기법을 제공한다. 다른 파일 시스템에 심각한 영향을 주는 I/O 로드는 이제 ZFS의 I/O 파이프라 인을 통해 손쉽게 대처할 수 있다.
ZFS는 상수범위 안에서 무제한적인 스냅샷과 클론들을 제공한다. 스냅샷은 읽기 전용의 파일시스템 복사본이고 클론은 스냅샷에 쓰기 기능이 더해진 것다.
클론은 워크스페이스나 소프트웨어 설치, 디스크가 없는 클라이언트등의 분야에서 최고의 공간절약 효율성을 제공한다.
ZFS 백업과 복구는 스냅샷에 의해 강력해 진다. 모든 스냅샷은 풀백업이 가능하고 또한 어떠한 짝의 스냅샷도 증가분 백업이 가능하다. 증가분 백업은 원격
replication에서 엄청나게 효과적인 방법이다. – 예를 들어 10초에 한번씩 증가분을 전송할 경우 ZFS에 한계는 없다. 사용자가 원하는 수 만큼의 파일을
만들 수 있다; 64비트 파일 오프셋, 무제한적인 링크와 디렉토리 엔트리, 그리고 스냅샷등을 이용하기 때문이다. ZFS는 기본적으로 압축을 제공한다.
공간을 2~3배 줄이는것 이상으로 I/O의 양을 2~3배 정도 줄요 주게 된다. 이러한 이유로 압축 옵션을 활성화 시킬 경우 많은 워크 로드들이 좀더 빠르게 처리 될 수
있을 것이다. 파일시스템과 더불어 ZFS 스토리지 풀은 raw-디바이스 구문이 필요한 어플리케이션들에게 볼륨을 제 공한다. ZFS 볼륨은 swap 디바이스로
사용 될 수 있다. 예를 들어 swap 볼륨에 압축 옵션을 활성화 한다면 사용자는 압축된 가상 메모리 공간을 가지게 되는 것이다.
2. ZFS 특징
The ZFS file system is a revolutionary new file system that fundamentally changes the way file
systems are administered, with features and benefits not found in any other file system
available today. ZFS has been designed to be robust, scalable, and simple to administer.
■ ZFS Pooled Storage
ZFS uses the concept of storage pools to manage physical storage. Historically, file systems
were constructed on top of a single physical device. To address multiple devices and provide
for data redundancy, the concept of a volume manager was introduced to provide the image of a
single device so that file systems would not have to be modified to take advantage of multiple
devices. This design added another layer of complexity and ultimately prevented certain file
system advances, because the file system had no control over the physical placement of data on
the virtualized volumes.
ZFS eliminates the volume management altogether. Instead of forcing you to create virtualized
volumes, ZFS aggregates devices into a storage pool. The storage pool describes the physical
characteristics of the storage (device layout, data redundancy, and so on,) and acts as an
arbitrary data store from which file systems can be created. File systems are no longer
constrained to individual devices, allowing them to share space with all file systems in the
pool. You no longer need to predetermine the size of a file system, as file systems grow
automatically within the space allocated to the storage pool. When new storage is added, all
file systems within the pool can immediately use the additional space without additional work.
In many ways, the storage pool acts as a virtual memory system. When a memoryDIMM is added to
a system, the operating system doesn’t force you to invoke some commands to configure the
memory and assign it to individual processes. All processes on the system automatically use
the additional memory.
■ Transactional Semantics
ZFS is a transactional file system, which means that the file system state is always
consistent on disk. Traditional file systems overwrite data in place, which means that if the
machine loses power, for example, between the time a data block is allocated and when it is
linked into a directory, the file system will be left in an inconsistent state.Historically,
this problem was solved through the use of the fsck command. This command was responsible for
going through and verifying file system state, making an attempt to repair any inconsistencies
in the process. This problem caused great pain to administrators and was never guaranteed to
fix all possible problems.More recently, file systems have introduced the concept of
journaling. The journaling process records action in a separate journal, which can then be
replayed safely if a system crash occurs. This process introduces unnecessary overhead,
because the data needs to be written twice, and often results in a new set of problems, such
as when the journal can’t be replayed properly.
With a transactional file system, data is managed using copy on write semantics. Data is never
overwritten, and any sequence of operations is either entirely committed or entirely ignored.
This mechanism means that the file system can never be corrupted through accidental loss of
power or a system crash. So, no need for a fsck equivalent exists. While the most recently
written pieces of data might be lost, the file system itself will always be consistent. In
addition, synchronous data (written using the O_DSYNC flag) is always guaranteed to be written
before returning, so it is never lost.
– 데이터 손상 원인에는 시스템 오류, 갑작스런 정전 등 여러 가지가 있지만 ZFS를 사용하면 이러한 예측 불허의 두려움에서 벗어날 수 있습니다.
즉, ZFS를 사용하면 언제나 데이터 일관성이 자동으로 유지되므로 데이터가 손상되지 않습니다. 모든 작업은 트랜잭션을 기반으로 이루어집니다.
이를 통해서 일관성이 유지될 뿐만 아니라 입출력 순서의 제한 사항이 대부분 해결되었고 변경 사항은 전체적으로 성공 또는 실패합니다.
– 또한 모든 작업은 COW(copy-on-write) 메커니즘을 기반으로 하며 사용 중인 데이터는 결코 덮어쓰기가 되지 않습니다.
ZFS에서는 데이터가 새 블록에 써진 후 데이터 포인터가 변경되고 쓰기가 커밋됩니다. 이와 같이 COW(copy-on-write) 메커니즘은
다음과 같은 장점이 있습니다.COW(copy-on-write) 메커니즘은 다음과 같은 장점이 있습니다.
– 디스크에 저장된 데이터가 항상 유효한 상태로 유지됩니다.
– 일관성과 신뢰성이 유지되면서 백업이 이루어집니다.
– 데이터가 알려진 일정 시점으로 롤백됩니다.
– 이제, 관리자는 시스템이 예상치 않게 갑자기 중단되어도 과거처럼 힘든 복구 과정(예: fsck)을 거치지 않아도 됩니다.
– 이 밖에도, ZFS에서는 유일하게 모든 데이터에 대해 엔드투엔드(end-to-end) 방식으로 64비트 체크섬이 이루어지기 때문에 경고 없이
데이터가 손상되지 않습니다. 즉, 데이터 읽기 작업이 이루어지면서 체크섬(checksums)을 통해 애플리케이션에서 쓴 데이터가 반환되었는지 확인됩니다.