ZFS File S"> Selected Notes on the ZFS File System

Layers

• device: HDD, SSD, iSCSI
• vdev: tree of: stripe, mirror, raidz1, raidz2, device
• pool: vdevs of: data, write cache, read cache
• transactional object layer
• zfs volume emulator, zfs posix layer, other file systems
• on posix layer: zfs file system, NFS, CIFS

Example of a hybrid storage pool

• raidz array of hard drives
• ZIL (write cache) PCIe NVRAM
• Level 2 ARC (read cache) flash SSD

ZFS Intent Log) write cache"> ZIL (ZFS Intent Log) write cache

• used for sync writes, transaction integrity
• separate ZIL device usually helps performance more than L2ARC
• write-only, except read at boot
• helps NFS, because the NFS protocol says all writes are sync
• no effect on read or async write workloads
• little benefit for sequential write workload
• max useful size is half of main memory

ARC (Adaptive Replacement Cache) read cache

• dynamically balances most-recently-used and most-frequently-used
• (level 1) ARC default target size is 7/8 physical memory
• L2ARC keeps its directory in kernel memory
• Dedup Table also uses ARC - lots of dedup objects need lots of RAM - field reports say L2ARC can help with dedup

Optimize devices

• data drives - GB/$ - big, slow, cheap
• ZIL - write latency/$ - fast, small
• L2ARC - fast random read, big enough

ZIO pipeline

• includes compress, dedup, checksum
• compress is fast and almost always a win
• dedup is especially good on backups and virtual machines

Accounting

• compression, dedup, and raidz complicate accounting
• the numbers don't add up, but are correct
• capacity planning can be challenging

Other features

• unlimited number of snapshots
• clones - read-write based on a snapshot
• recently added user and group quotas

Links

• http://nexenta.org
• http://zfsonlinux.org
• http://hub.opensolaris.org/bin/view/Community+Group+zfs
• http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide