ZFS文件系统的特点以及调优

Record Size
Record Size 也就是通常所说的文件系统的block size。ZFS采用的是动态的Record Size，也就
是说ZFS会根据文件大小选择*适合*的512字节的整数倍作为存储的块大小，最大的Record
Size为128KB。通常没有必要手工设置Record Size。如果手工把Record Size调小，将不会得
到空间的节省，并且常常会影响性能。ZFS的Block是计算checksum的单位，一个文件用到
的block越多，计算checksum以及维护metadata的开销就会越大。
目前ZFS的版本下，只有一种情况需要手工调小Record Size：大文件上的小数据量的更新。
常见的情况是数据库的数据文件在ZFS上，并且是做OLTP为主的应用。原因是大文件的
blocksize是128KB，如果只更新其中一小部分数据，由于ZFS是copy-on-write的方式来更新
数据，这种情况下仍然要读写128KB的数据，造成了不必要的开销。
另外，修改了Record Size后，对之前创建的文件不起作用。

ARC (Adaptive Replacement Cache)
这实际上是ZFS的文件系统的cache。它是一个可以自动伸缩的cache。目前一个操作系统实
例里只有一个ARC，不管这个操作系统上有多少个ZFS Pool。而且metadata和实际的数据都
共用这个ARC。
如果没有其它应用或操作系统本身争用内存，ZFS会尽可能多地使用物理内存作为cache。如
果事先知道应用程序或操作系统需要使用多少内存，可以考虑限制ARC的大小。在/etc/system
中设置，例子：set zfs:zfs_arc_max=0x200000000 （设置ARC最大为8GB）

TXG (Transaction Groups)
应用的文件写操作一般分为两种，同步写和普通写操作。同步写是指写操作必须物理地写到
存储介质上才能返回给应用，通常这种情况发生在open文件时指定了O_DSYNC或O_SYNC
属性，以及调用fsync()等；普通写操作是指写操作写到文件系统cache里即可返回给应用，通
常以普通方式打开文件后的write()，fwrite()操作都是这种操作。TXG (Transaction Groups)则是
负责管理如何将文件系统cache（ARC）里的数据同步到磁盘上的机制。
对于写进文件系统cache里的每一个数据都会被编入一个TXG，通常情况下每隔5秒钟或文件
系统cache里有太多脏数据（待写入磁盘的数据达到ARC的一半），当前TXG里的所有数据
会被同步到磁盘，同时启动下一个TXG。每一个ZFS Pool同时最多会有3个TXG，分别处于
3种状态：open, quiescing, syncing。当TXG不能在5秒内把数据同步到磁盘上时将会影响
open TXG，从而引起应用写操作的阻塞。这个现象叫做写抑制（throttling）。
当前的Solaris 版本（Solaris 10 8/07）对写抑制的控制不是非常好，当进行密集的写操作并且
ARC较大、磁盘系统较慢时容易使TXG同步数据的时间非常长，发生throttling从而使应用的
后续写操作的响应时间非常长。在新的opensolaris发行包里，这个问题已经有了很大的改进，
ZFS会监测ARC接收数据的速度和ARC数据同步到磁盘上的速度，并自动调整ARC接收数
据的速度。另外ARC脏数据的大小限制改为1/8物理内存。通过这种控制可以使应用的写操
作响应时间更为均匀稳定。

ZIL (ZFS Intent Log)
对于同步写操作，ZFS为系统中每一个ZFS文件系统维护一个ZIL(ZFS Intent log)。同步写操
作的数据会先写入ZIL，并且会把磁盘的write cache的数据同步到磁盘上，然后应用的写操作
返回。当文件提交命令发生时，ZFS会把ZIL里该文件的数据同步到磁盘上。
缺省情况下，ZIL是在ZFS存储池中动态分配的。某些同步写操作（比如数据库的联机重做日
志或NFS COMMIT）如果响应时间慢将会极大影响性能。为了不使ZIL受其它I/O操作的影
响，可以考虑采用一个专门的快速设备如NVRAM，SSD(Solid State Disk)等做ZIL，以下命令
为ZFS存储池添加专用的ZIL:
zpool add <pool> log <log devices>
另外，由于每次同步写操作会使ZFS把磁盘 write cache的数据同步到磁盘上，对于SAN的存
储，频繁地flush cache会严重影响性能并且是不必要的。这个问题在OpenSolaris里已经得到
解决，解决办法是让设备驱动程序向存储系统发出适当的命令选项，从而使存储系统可以忽
略从non-volatile cache同步到磁盘的请求。前提是存储系统可以识别驱动程序发出的命令选项。

I/O scheduler and priorities
缺省情况下，ZFS会限制每一个它能看到的存储池里的设备的I/O队列长度为35，并且通常读
操作的优先级高于写操作。这种做法的目的是保证较好的I/O service time。
根据实际的应用需求和存储设备的不同，可能需要调整I/O队列的大小。比如为了得到更好地
响应时间，在/etc/system里设置：set zfs:zfs_vdev_max_pending = 10

Prefetch (file level and device level)
和其它文件系统一样，ZFS也有预读的功能。ZFS文件系统的预读分为file-level和devicelevel
。
file-level的预读是指ZFS可以检测到文件读取的模式，预先读入文件的后续部分从而减少I/O
操作以提高性能。对于大并发量的针对不同文件的读操作，file-level的预读通常不会带来好处，
可以把预读关掉：在/etc/system里设置：set zfs:zfs_prefetch_disable = 1 。
Device-level的预读是指在读取数据块时，会读取设备相邻的数据，假定相邻数据随后会被用
到。Device-level的预读有时会读入不需要的数据反而会影响性能，在新的opensolaris发行包
里，Device-level的预读只预读metadata。

RAIDZ and RAIDZ2
ZFS提供了类似传统RAID5和RAID6的功能，分别叫做RAIDZ和RAIDZ2。但RAIDZ的实
现与传统RAID5有很大不同：RAIDZ的所有写操作都是Full-Stripe write，结合ZFS的copyon-
write和checksum的机制，可以保证数据的一致性，无需像传统的RAID5那样需要昂贵的
NVRAM来保证条带数据的一致性。
RAIDZ的stripe size是完全动态的。每一个文件系统块(record)在存储时会平均分配到RAIDZ
group里的所有磁盘上，并以512字节为单位。例如，假设一个4KB的文件，如果存储在4+1
的RAIDZ group，则4KB的数据会分散到4个磁盘上，每个磁盘上存储1KB。因此一个
RAIDZ group里的设备不应过多，否则会影响读操作的性能。一般建议为3~9个。RAIDZ比
较适合大文件的顺序读写。
由于RAIDZ在设计上的特殊性，在数据恢复时需要通过metadata来恢复，要遍历整个pool。
当某块磁盘出现故障时，RAIDZ重建的速度与metadata的数量有关。当有大量metadata数据
时，比如大量snapshots或pool里的文件数量庞大，数据重建的速度会较慢。在这种情况下，
可以考虑创建多个pool。当然，对一个很空的文件系统，RAIDZ的重建时间会很短。