2. Documentation
3. books/handbook/zfs/_index
4. Korean

Each dataset has a compression property, which defaults to off. Set this property to an available compression algorithm. This causes compression of all new data written to the dataset. Beyond a reduction in space used, read and write throughput often increases because fewer blocks need reading or writing.

[[zfs-term-compression-lz4]]
* _LZ4_ - Added in ZFS pool version 5000 (feature flags), LZ4 is now the recommended compression algorithm. LZ4 works about 50% faster than LZJB when operating on compressible data, and is over three times faster when operating on uncompressible data. LZ4 also decompresses about 80% faster than LZJB. On modern CPUs, LZ4 can often compress at over 500 MB/s, and decompress at over 1.5 GB/s (per single CPU core).

[[zfs-term-compression-lzjb]]
* _LZJB_ - The default compression algorithm. Created by Jeff Bonwick (one of the original creators of ZFS). LZJB offers good compression with less CPU overhead compared to GZIP. In the future, the default compression algorithm will change to LZ4.

[[zfs-term-compression-gzip]]
* _GZIP_ - A popular stream compression algorithm available in ZFS. One of the main advantages of using GZIP is its configurable level of compression. When setting the `compress` property, the administrator can choose the level of compression, ranging from `gzip1`, the lowest level of compression, to `gzip9`, the highest level of compression. This gives the administrator control over how much CPU time to trade for saved disk space.

[[zfs-term-compression-zle]]
* _ZLE_ - Zero Length Encoding is a special compression algorithm that compresses continuous runs of zeros alone. This compression algorithm is useful when the dataset contains large blocks of zeros.

각 데이터 세트에는 압축 속성이 있으며, 기본값은 꺼짐입니다. 이 속성을 사용 가능한 압축 알고리즘으로 설정합니다. 이렇게 하면 데이터 세트에 새로 쓰여지는 모든 데이터가 압축됩니다. 사용되는 공간이 줄어드는 것 외에도 읽기 또는 쓰기가 필요한 블록이 줄어들기 때문에 읽기 및 쓰기 처리량이 증가하는 경우가 많습니다.

[[zfs-term-compression-lz4]]
* _LZ4_ - ZFS 풀 버전 5000 (기능 플래그)에 추가된 LZ4는 이제 권장 압축 알고리즘입니다. LZ4는 압축 가능한 데이터에서 작동할 때 LZJB보다 약 50% 더 빠르게 작동하며, 압축 불가능한 데이터에서 작동할 때는 3배 이상 더 빠릅니다. 또한 LZ4는 LZJB보다 약 80% 더 빠르게 압축을 해제합니다. 최신 CPU에서 LZ4는 종종 500MB/s 이상의 속도로 압축하고 1.5GB/s 이상의 속도로 압축을 해제할 수 있습니다(단일 CPU 코어당).

[[zfs-term-compression-lzjb]]
* _LZJB_ - 기본 압축 알고리즘입니다. Jeff Bonwick (ZFS의 최초 개발자 중 한 명)이 만들었습니다. LZJB는 GZIP에 비해 CPU 오버헤드가 적으면서도 우수한 압축 성능을 제공합니다. 앞으로 기본 압축 알고리즘은 LZ4로 변경될 예정입니다.

[[zfs-term-compression-gzip]]
* _GZIP_ - ZFS에서 널리 사용되는 스트림 압축 알고리즘입니다. GZIP 사용의 주요 장점 중 하나는 압축 수준을 구성할 수 있다는 것입니다. `compress` 속성을 설정할 때 관리자는 가장 낮은 압축 수준인 `gzip1` 부터 가장 높은 압축 수준인 `gzip9` 까지 압축 수준을 선택할 수 있습니다. 이를 통해 관리자는 절약된 디스크 공간과 교환할 CPU 시간을 제어할 수 있습니다.

[[zfs-term-compression-zle]]
* _ZLE_ - Zero Length Encoding은 0의 연속 실행만을 압축하는 특수 압축 알고리즘입니다. 이 압축 알고리즘은 데이터 세트에 큰 0 블록이 포함되어 있을 때 유용합니다.

Each dataset has a compression property, which defaults to off. Set this property to an available compression algorithm. This causes compression of all new data written to the dataset. Beyond a reduction in space used, read and write throughput often increases because fewer blocks need reading or writing.

[[zfs-term-compression-lz4]]
* _LZ4_ - Added in ZFS pool version 5000 (feature flags), LZ4 is now the recommended compression algorithm. LZ4 works about 50% faster than LZJB when operating on compressible data, and is over three times faster when operating on uncompressible data. LZ4 also decompresses about 80% faster than LZJB. On modern CPUs, LZ4 can often compress at over 500 MB/s, and decompress at over 1.5 GB/s (per single CPU core).

[[zfs-term-compression-lzjb]]
* _LZJB_ - The default compression algorithm. Created by Jeff Bonwick (one of the original creators of ZFS). LZJB offers good compression with less CPU overhead compared to GZIP. In the future, the default compression algorithm will change to LZ4.

[[zfs-term-compression-gzip]]
* _GZIP_ - A popular stream compression algorithm available in ZFS. One of the main advantages of using GZIP is its configurable level of compression. When setting the `compress` property, the administrator can choose the level of compression, ranging from `gzip1`, the lowest level of compression, to `gzip9`, the highest level of compression. This gives the administrator control over how much CPU time to trade for saved disk space.

[[zfs-term-compression-zle]]
* _ZLE_ - Zero Length Encoding is a special compression algorithm that compresses continuous runs of zeros alone. This compression algorithm is useful when the dataset contains large blocks of zeros.

Transaction Groups are the way ZFS groups blocks changes together and writes them to the pool. Transaction groups are the atomic unit that ZFS uses to ensure consistency. ZFS assigns each transaction group a unique 64-bit consecutive identifier. There can be up to three active transaction groups at a time, one in each of these three states:

* _Open_ - A new transaction group begins in the open state and accepts new
writes. There is always a transaction group in the open state, but the
transaction group may refuse new writes if it has reached a limit. Once the
open transaction group has reached a limit, or reaching the
crossref:zfs[zfs-advanced-tuning-txg-timeout,`vfs.zfs.txg.timeout`], the transaction group advances to the next state.
* _Quiescing_ - A short state that allows any pending operations to finish without blocking the creation of a new open transaction group. Once all the transactions in the group have completed, the transaction group advances to the final state.
* _Syncing_ - Write all the data in the transaction group to stable storage.
This process will in turn change other data, such as metadata and space maps,
that ZFS will also write to stable storage. The process of syncing involves
several passes. On the first and biggest, all the changed data blocks; next
come the metadata, which may take several passes to complete. Since allocating
space for the data blocks generates new metadata, the syncing state cannot
finish until a pass completes that does not use any new space. The syncing
state is also where _synctasks_ complete. Synctasks are administrative
operations such as creating or destroying snapshots and datasets that complete
the uberblock change. Once the sync state completes the transaction group in
the quiescing state advances to the syncing state. All administrative
functions, such as crossref:zfs[zfs-term-snapshot,`snapshot`] write as part of the transaction group. ZFS adds a created synctask to the open transaction group, and that group advances as fast as possible to the syncing state to reduce the latency of administrative commands.

트랜잭션 그룹은 ZFS가 블록 변경 사항을 함께 그룹화하여 풀에 쓰는 방식입니다. 트랜잭션 그룹은 ZFS가 일관성을 보장하기 위해 사용하는 원자 단위입니다. ZFS는 각 트랜잭션 그룹에 고유한 64비트 연속 식별자를 할당합니다. 한 번에 최대 3개의 활성 트랜잭션 그룹이 있을 수 있으며, 이 세 가지 상태 각각에 하나씩 있습니다:

* _Open_ - 새 트랜잭션 그룹이 개방 상태에서 시작하여 새 쓰기를 수락합니다. 항상 열려 있는 상태의 트랜잭션 그룹이 있지만, 트랜잭션 그룹이 한도에 도달하면 새 쓰기를 거부할 수 있습니다. 열려 있는 트랜잭션 그룹이 한도에 도달하거나 <<zfs-advanced-tuning-txg-timeout,`vfs.zfs.txg.timeout`>> 에 도달하면 트랜잭션 그룹은 다음 상태로 진행합니다.
* _Quiescing_ - 새로운 미결 트랜잭션 그룹 생성을 차단하지 않고 보류 중인 모든 작업을 완료할 수 있는 짧은 상태입니다. 그룹의 모든 트랜잭션이 완료되면 트랜잭션 그룹은 최종 상태로 진행됩니다.
* _Syncing_ - 트랜잭션 그룹의 모든 데이터를 안정적인 스토리지에 씁니다. 이 프로세스는 메타데이터 및 스페이스 맵과 같은 다른 데이터도 변경하여 ZFS가 안정적인 스토리지에 기록합니다. 동기화 프로세스에는 여러 번의 패스가 포함됩니다. 가장 먼저 변경된 모든 데이터 블록이 동기화되고, 다음으로 메타데이터가 동기화되며, 이 작업은 여러 번에 걸쳐 진행됩니다. 데이터 블록에 공간을 할당하면 새 메타데이터가 생성되므로 새 공간을 사용하지 않는 패스가 완료될 때까지 동기화 상태가 완료될 수 없습니다. 동기화 상태는 _synctasks_ 가 완료되는 지점이기도 합니다. Synctasks는 uberblock 변경을 완료하는 스냅샷 및 데이터세트 생성 또는 삭제와 같은 관리 작업입니다. 동기화 상태가 완료되면 대기 상태의 트랜잭션 그룹이 동기화 상태로 진행됩니다. <<zfs-term-snapshot,`snapshot`>> 과 같은 모든 관리 함수는 트랜잭션 그룹의 일부로 기록하게 됩니다. ZFS는 생성된 synctask를 열린 트랜잭션 그룹에 추가하고, 해당 그룹은 관리 명령의 대기 시간을 줄이기 위해 가능한 한 빨리 동기화 상태로 진행합니다.

Transaction Groups are the way ZFS groups blocks changes together and writes them to the pool. Transaction groups are the atomic unit that ZFS uses to ensure consistency. ZFS assigns each transaction group a unique 64-bit consecutive identifier. There can be up to three active transaction groups at a time, one in each of these three states:

* _Open_ - A new transaction group begins in the open state and accepts new
writes. There is always a transaction group in the open state, but the
transaction group may refuse new writes if it has reached a limit. Once the
open transaction group has reached a limit, or reaching the <<
crossref:zfs[zfs-advanced-tuning-txg-timeout,`vfs.zfs.txg.timeout`>>], the transaction group advances to the next state.
* _Quiescing_ - A short state that allows any pending operations to finish without blocking the creation of a new open transaction group. Once all the transactions in the group have completed, the transaction group advances to the final state.
* _Syncing_ - Write all the data in the transaction group to stable storage.
This process will in turn change other data, such as metadata and space maps,
that ZFS will also write to stable storage. The process of syncing involves
several passes. On the first and biggest, all the changed data blocks; next
come the metadata, which may take several passes to complete. Since allocating
space for the data blocks generates new metadata, the syncing state cannot
finish until a pass completes that does not use any new space. The syncing
state is also where _synctasks_ complete. Synctasks are administrative
operations such as creating or destroying snapshots and datasets that complete
the uberblock change. Once the sync state completes the transaction group in
the quiescing state advances to the syncing state. All administrative
functions, such as <<crossref:zfs[zfs-term-snapshot,`snapshot`>>] write as part of the transaction group. ZFS adds a created synctask to the open transaction group, and that group advances as fast as possible to the syncing state to reduce the latency of administrative commands.

A pool consists of one or more vdevs, which themselves are a single disk or a group of disks, transformed to a RAID. When using a lot of vdevs, ZFS spreads data across the vdevs to increase performance and maximize usable space. All vdevs must be at least 128 MB in size.

* [[zfs-term-vdev-disk]] _Disk_ - The most basic vdev type is a standard block device. This can be an entire disk (such as [.filename]#/dev/ada0# or [.filename]#/dev/da0#) or a partition ([.filename]#/dev/ada0p3#). On FreeBSD, there is no performance penalty for using a partition rather than the entire disk. This differs from recommendations made by the Solaris documentation.
+
[CAUTION]
====
Using an entire disk as part of a bootable pool is strongly discouraged, as this may render the pool unbootable.
Likewise, you should not use an entire disk as part of a mirror or RAID-Z vdev.
Reliably determining the size of an unpartitioned disk at boot time is impossible and there's no place to put in boot code.
====

* [[zfs-term-vdev-file]] _File_ - Regular files may make up ZFS pools, which is useful for testing and experimentation. Use the full path to the file as the device path in `zpool create`.
* [[zfs-term-vdev-mirror]] _Mirror_ - When creating a mirror, specify the `mirror` keyword followed by the list of member devices for the mirror. A mirror consists of two or more devices, writing all data to all member devices. A mirror vdev will hold as much data as its smallest member. A mirror vdev can withstand the failure of all but one of its members without losing any data.
+
[NOTE]
====
To upgrade a regular single disk vdev to a mirror vdev at any time, use `zpool
crossref:zfs[zfs-zpool-attach,attach]`.
====

* [[zfs-term-vdev-raidz]] _RAID-Z_ - ZFS uses RAID-Z, a variation on standard RAID-5 that offers better distribution of parity and eliminates the "RAID-5 write hole" in which the data and parity information become inconsistent after an unexpected restart. ZFS supports three levels of RAID-Z which provide varying levels of redundancy in exchange for decreasing levels of usable storage. ZFS uses RAID-Z1 through RAID-Z3 based on the number of parity devices in the array and the number of disks which can fail before the pool stops being operational.
+
In a RAID-Z1 configuration with four disks, each 1 TB, usable storage is 3 TB and the pool will still be able to operate in degraded mode with one faulted disk. If another disk goes offline before replacing and resilvering the faulted disk would result in losing all pool data.
+
In a RAID-Z3 configuration with eight disks of 1 TB, the volume will provide 5 TB of usable space and still be able to operate with three faulted disks. Sun(TM) recommends no more than nine disks in a single vdev. If more disks make up the configuration, the recommendation is to divide them into separate vdevs and stripe the pool data across them.
+
A configuration of two RAID-Z2 vdevs consisting of 8 disks each would create something like a RAID-60 array. A RAID-Z group's storage capacity is about the size of the smallest disk multiplied by the number of non-parity disks. Four 1 TB disks in RAID-Z1 has an effective size of about 3 TB, and an array of eight 1 TB disks in RAID-Z3 will yield 5 TB of usable space.
* [[zfs-term-vdev-spare]] _Spare_ - ZFS has a special pseudo-vdev type for keeping track of available hot spares. Note that installed hot spares are not deployed automatically; manually configure them to replace the failed device using `zfs replace`.
* [[zfs-term-vdev-log]] _Log_ - ZFS Log Devices, also known as ZFS Intent Log
(crossref:zfs[zfs-term-zil,ZIL]) move the intent log from the regular pool devices to a dedicated device, typically an SSD. Having a dedicated log device improves the performance of applications with a high volume of synchronous writes like databases. Mirroring of log devices is possible, but RAID-Z is not supported. If using a lot of log devices, writes will be load-balanced across them.
* [[zfs-term-vdev-cache]] _Cache_ - Adding a cache vdev to a pool will add the
storage of the cache to the crossref:zfs[zfs-term-l2arc,L2ARC]. Mirroring cache devices is impossible. Since a cache device stores only new copies of existing data, there is no risk of data loss.

풀은 하나 이상의 vdev로 구성되며, 하나 이상의 vdev는 그 자체로 단일 디스크이거나 RAID로 변환된 디스크 그룹입니다. 많은 수의 vdev를 사용하는 경우, ZFS는 성능을 높이고 사용 가능한 공간을 최대화하기 위해 vdev에 데이터를 분산시킵니다. 모든 vdev의 크기는 128MB 이상이어야 합니다.

* [[zfs-term-vdev-disk]] _Disk_ - 가장 기본적인 vdev 유형은 표준 블록 장치입니다. 이것은 전체 디스크( 예: [.filename]#/dev/ada0# 또는 [.filename]#/dev/da0# ) 또는 파티션( [.filename]#/dev/ada0p3# )이 될 수 있습니다. FreeBSD에서는 전체 디스크가 아닌 파티션을 사용해도 성능에 대한 불이익이 없습니다. 이는 Solaris 설명서의 권장 사항과 다릅니다.
+
[CAUTION]
====
전체 디스크를 부팅 가능한 풀의 일부로 사용하는 것은 풀을 부팅할 수 없게 만들 수 있으므로 절대 권장하지 않습니다.
마찬가지로 전체 디스크를 미러 또는 RAID-Z vdev의 일부로 사용해서는 안 됩니다.
부팅 시 파티션되지 않은 디스크의 크기를 안정적으로 결정하는 것은 불가능하며 부트 코드를 넣을 수 있는 위치가 없습니다.
====

* [[zfs-term-vdev-file]] _File_ - 테스트 및 실험에 유용한 일반 파일이 ZFS 풀을 구성할 수 있습니다. 파일의 전체 경로를 `zpool create` 의 장치 경로로 사용합니다.
* [[zfs-term-vdev-mirror]] _Mirror_ - 미러를 생성할 때 `mirror` 키워드 뒤에 미러의 구성원 장치 목록을 지정합니다. 미러는 두 개 이상의 장치로 구성되며, 모든 데이터를 모든 구성원 장치에 기록합니다. 미러 vdev는 가장 작은 멤버만큼의 데이터를 보유합니다. 미러 디바이스는 멤버 중 한 대를 제외한 모든 디바이스가 장애가 발생해도 데이터 손실 없이 견딜 수 있습니다.
+
[NOTE]
====
일반 단일 디스크 vdev를 언제든지 미러 vdev로 업그레이드하려면 `zpool <<zfs-zpool-attach,attach>>` 를 사용합니다.
====

* [[zfs-term-vdev-raidz]] _RAID-Z_ - ZFS는 더 나은 패리티 분배를 제공하고 예기치 않은 재시작 후 데이터와 패리티 정보가 일치하지 않는 “RAID-5 write hole”을 제거하는 표준 RAID-5의 변형인 RAID-Z를 사용합니다. ZFS는 사용 가능한 스토리지의 수준을 낮추는 대신 다양한 수준의 중복성을 제공하는 세 가지 레벨의 RAID-Z를 지원합니다. ZFS는 어레이의 패리티 디바이스 수와 풀이 작동을 멈추기 전에 장애가 발생할 수 있는 디스크 수에 따라 RAID-Z1부터 RAID-Z3까지 사용합니다.
+
각각 1TB씩 4개의 디스크가 있는 RAID-Z1 구성에서 사용 가능한 스토리지는 3TB이며, 하나의 디스크에 오류가 발생해도 풀은 여전히 성능 저하 모드로 작동할 수 있습니다. 장애가 발생한 디스크를 교체하고 복구하기 전에 다른 디스크가 오프라인 상태가 되면 모든 풀 데이터가 손실될 수 있습니다.
+
1TB의 디스크 8개를 사용하는 RAID-Z3 구성의 경우, 이 볼륨은 5TB의 가용 공간을 제공하면서도 3개의 디스크 장애상태에서도 작동할 수 있습니다. Sun(TM)은 단일 vdev에 9개 이하의 디스크를 사용할 것을 권장합니다. 더 많은 디스크가 구성을 구성하는 경우, 이를 별도의 vdev로 분할하여 풀 데이터를 스트라이핑하는 것이 좋습니다.
+
각각 8개의 디스크로 구성된 2개의 RAID-Z2 vdev를 구성하면 RAID-60 어레이와 같은 구성이 됩니다. RAID-Z 그룹의 스토리지 용량은 가장 작은 디스크의 크기에 패리티가 아닌 디스크의 수를 곱한 값입니다. RAID-Z1의 1TB 디스크 4개는 약 3TB의 유효 크기를 가지며, RAID-Z3의 1TB 디스크 8개로 구성된 어레이는 5TB의 사용 가능한 공간을 확보합니다.
* [[zfs-term-vdev-spare]] _Spare_ - ZFS에는 사용 가능한 핫 스페어를 추적하기 위한 특수한 pseudo-vdev 유형이 있습니다. 설치된 핫 스페어는 자동으로 배포되지 않으므로 `zfs replace` 를 사용하여 장애가 발생한 장치를 대체하도록 수동으로 구성해야 합니다.
* [[zfs-term-vdev-log]] _Log_ - ZFS Intent Log (<<zfs-term-zil,ZIL>>)라고도 하는 ZFS 로그 장치는 인텐트 로그를 일반 풀 장치에서 전용 장치(일반적으로 SSD)로 이동 시킵니다. 전용 로그 장치를 사용하면 데이터베이스와 같이 동기식 쓰기량이 많은 애플리케이션의 성능이 향상됩니다. 로그 장치의 미러링은 가능하지만 RAID-Z는 지원하지 않습니다. 많은 로그 장치를 사용하는 경우 쓰기 작업이 장치 간에 로드 밸런싱됩니다.
* [[zfs-term-vdev-cache]] _Cache_ - 풀에 cache vdev를 추가하면 캐시의 스토리지가 <<zfs-term-l2arc,L2ARC>> 에 추가됩니다. 캐시 디바이스 미러링은 불가능합니다. 캐시 장치는 기존 데이터의 새 복사본만 저장하므로 데이터 손실의 위험이 없습니다.

A pool consists of one or more vdevs, which themselves are a single disk or a group of disks, transformed to a RAID. When using a lot of vdevs, ZFS spreads data across the vdevs to increase performance and maximize usable space. All vdevs must be at least 128 MB in size.

* [[zfs-term-vdev-disk]] _Disk_ - The most basic vdev type is a standard block device. This can be an entire disk (such as [.filename]#/dev/ada0# or [.filename]#/dev/da0#) or a partition ([.filename]#/dev/ada0p3#). On FreeBSD, there is no performance penalty for using a partition rather than the entire disk. This differs from recommendations made by the Solaris documentation.
+
[CAUTION]
====
Using an entire disk as part of a bootable pool is strongly discouraged, as this may render the pool unbootable.
Likewise, you should not use an entire disk as part of a mirror or RAID-Z vdev.
Reliably determining the size of an unpartitioned disk at boot time is impossible and there's no place to put in boot code.
====

* [[zfs-term-vdev-file]] _File_ - Regular files may make up ZFS pools, which is useful for testing and experimentation. Use the full path to the file as the device path in `zpool create`.
* [[zfs-term-vdev-mirror]] _Mirror_ - When creating a mirror, specify the `mirror` keyword followed by the list of member devices for the mirror. A mirror consists of two or more devices, writing all data to all member devices. A mirror vdev will hold as much data as its smallest member. A mirror vdev can withstand the failure of all but one of its members without losing any data.
+
[NOTE]
====
To upgrade a regular single disk vdev to a mirror vdev at any time, use `zpool <<
crossref:zfs[zfs-zpool-attach,attach>>]`.
====

* [[zfs-term-vdev-raidz]] _RAID-Z_ - ZFS uses RAID-Z, a variation on standard RAID-5 that offers better distribution of parity and eliminates the "RAID-5 write hole" in which the data and parity information become inconsistent after an unexpected restart. ZFS supports three levels of RAID-Z which provide varying levels of redundancy in exchange for decreasing levels of usable storage. ZFS uses RAID-Z1 through RAID-Z3 based on the number of parity devices in the array and the number of disks which can fail before the pool stops being operational.
+
In a RAID-Z1 configuration with four disks, each 1 TB, usable storage is 3 TB and the pool will still be able to operate in degraded mode with one faulted disk. If another disk goes offline before replacing and resilvering the faulted disk would result in losing all pool data.
+
In a RAID-Z3 configuration with eight disks of 1 TB, the volume will provide 5 TB of usable space and still be able to operate with three faulted disks. Sun(TM) recommends no more than nine disks in a single vdev. If more disks make up the configuration, the recommendation is to divide them into separate vdevs and stripe the pool data across them.
+
A configuration of two RAID-Z2 vdevs consisting of 8 disks each would create something like a RAID-60 array. A RAID-Z group's storage capacity is about the size of the smallest disk multiplied by the number of non-parity disks. Four 1 TB disks in RAID-Z1 has an effective size of about 3 TB, and an array of eight 1 TB disks in RAID-Z3 will yield 5 TB of usable space.
* [[zfs-term-vdev-spare]] _Spare_ - ZFS has a special pseudo-vdev type for keeping track of available hot spares. Note that installed hot spares are not deployed automatically; manually configure them to replace the failed device using `zfs replace`.
* [[zfs-term-vdev-log]] _Log_ - ZFS Log Devices, also known as ZFS Intent Log (<<
(crossref:zfs[zfs-term-zil,ZIL>>]) move the intent log from the regular pool devices to a dedicated device, typically an SSD. Having a dedicated log device improves the performance of applications with a high volume of synchronous writes like databases. Mirroring of log devices is possible, but RAID-Z is not supported. If using a lot of log devices, writes will be load-balanced across them.
* [[zfs-term-vdev-cache]] _Cache_ - Adding a cache vdev to a pool will add the
storage of the cache to the <<crossref:zfs[zfs-term-l2arc,L2ARC>>]. Mirroring cache devices is impossible. Since a cache device stores only new copies of existing data, there is no risk of data loss.

# zpool iostat -v
capacity operations bandwidth
pool alloc free read write read write
----------------------- ----- ----- ----- ----- ----- -----
data 288G 1.53T 2 12 9.23K 61.5K
mirror 288G 1.53T 2 12 9.23K 61.5K
ada1 - - 0 4 5.61K 61.7K
ada2 - - 1 4 5.04K 61.7K
----------------------- ----- ----- ----- ----- ----- -----

# zpool iostat -v
capacity operations bandwidth
pool alloc free read write read write
----------------------- ----- ----- ----- ----- ----- -----
data 288G 1.53T 2 12 9.23K 61.5K
mirror 288G 1.53T 2 12 9.23K 61.5K
ada1 - - 0 4 5.61K 61.7K
ada2 - - 1 4 5.04K 61.7K
----------------------- ----- ----- ----- ----- ----- -----

# zpool iostat -v
capacity operations bandwidth
pool alloc free read write read write
----------------------- ----- ----- ----- ----- ----- -----
data 288G 1.53T 2 12 9.23K 61.5K
mirror 288G 1.53T 2 12 9.23K 61.5K
ada1 - - 0 4 5.61K 61.7K
ada2 - - 1 4 5.04K 61.7K
----------------------- ----- ----- ----- ----- ----- -----