ZFS文件系统
2014-12-06 20:23:57 
阿炯
ZFS源自于Sun Microsystems为Solaris操作系统开发的文件系统。它是一个具有高存储容量、文件系统与卷管理概念集成、崭新的磁盘逻辑结构的轻量级文件系统，同时也是一个便捷的存储池管理系统。ZFS是一个使用Common Development and Distribution License(CDDL)协议条款授权的开源项目。其命名来源发想于"Zettabyte File System"的首字母缩写。但它本身并不具备任何的缩写意涵，只是作者想阐述做为一个具备高扩充容量文件系统且还有支持许多延伸功能的一个产品。
ZFS的设计与开发由Sun公司的Jeff Bonwick所领导的一支团队完成。最早宣布于2004年9月14日，于2005年10月31日并入了Solaris开发的主干源代码。ZFS 文件系统是一种革新性的新文件系统，可从根本上改变文件系统的管理方式，并具有目前面市的其他任何文件系统所没有的功能和优点。ZFS 强健可靠、可伸缩、易于管理。
ZFS 使用存储池的概念来管理物理存储，以前文件系统是在单个物理设备的基础上构造的。为了利用多个设备和提供数据冗余性，引入了卷管理器的概念来提供单个设备的表示，以便无需修改文件系统即可利用多个设备。此设计增加了更多复杂性，并最终阻碍了特定文件系统的继续发展，因为这类文件系统无法控制数据在虚拟卷上的物理放置。
ZFS 可完全避免使用卷管理。ZFS 将设备聚集到存储池中，而不是强制要求创建虚拟卷。存储池说明了存储的物理特征(设备布局、数据冗余等)，并充当可以从其创建文件系统的任意数据存储库。文件系统不再仅限于单个设备，从而可与池中的所有文件系统共享磁盘空间。您不再需要预先确定文件系统的大小，因为文件系统会在分配给存储池的磁盘空间内自动增长。添加新存储器后，无需执行其他操作，池中的所有文件系统即可立即使用所增加的磁盘空间。在许多方面，存储池与虚拟内存系统相似：将一个内存 DIMM 加入系统时，操作系统并不强迫您运行命令来配置内存并将其指定给个别进程。系统中的所有进程都会自动使用所增加的内存。
ZFS 是事务性文件系统，这意味着文件系统状态在磁盘上始终是一致的。传统文件系统可就地覆写数据，这意味着如果系统断电(例如，在分配数据块到将其链接到目录中的时间段内断电)，则会使文件系统处于不一致状态。以前，此问题是通过使用fsck命令解决的。此命令负责检查并验证文件系统状态，并尝试在操作过程中修复任何不一致性。这种文件系统不一致问题曾给管理员造成巨大困扰，fsck命令并不保证能够解决所有可能的问题。最近文件系统引入了日志记录的概念。日志记录过程在单独的日志中记录操作，在系统发生崩溃时，可以安全地重放该日志。由于数据需要写入两次，因此该过程会引入不必要的开销，而且通常会导致一组新问题，例如在无法正确地重放日志时。
对于事务性文件系统，数据是使用写复制语义管理的。数据永远不会被覆写，并且任何操作序列会全部被提交或全部被忽略。因此文件系统绝对不会因意外断电或系统崩溃而被损坏。尽管最近写入的数据片段可能丢失，但是文件系统本身将始终是一致的。此外，只有在写入同步数据(使用O_DSYNC标志写入)后才返回，因此同步数据决不会丢失。
对于 ZFS，所有数据和元数据都通过用户可选择的校验和算法进行验证。提供校验和验证的传统文件系统出于卷管理层和传统文件系统设计的必要，会逐块执行此操作。在传统设计中，某些故障可能导致数据不正确但没有校验和错误，如向错误位置写入完整的块等。ZFS 校验和的存储方式可确保检测到这些故障并可以正常地从其中进行恢复。所有校验和验证与数据恢复都是在文件系统层 执行的，并且对应用程序是透明的。
此外，ZFS 还会提供自我修复数据。ZFS 支持存储池具有各种级别的数据冗余性。检测到坏的数据块时，ZFS 会从另一个冗余副本中提取正确的数据，而且会用正确的数据替换错误的数据。
ZFS引入了一个新的数据复制模型，称为RAID-Z。它与RAID-5 类似，但采用可变条带宽度来消除RAID-5 写入漏洞(即由于数据和奇偶校验更新之间出现意外断电而导致条带损坏)。所有RAID-Z 写操作都是完整条带化写操作。这样，既没有读取-修改-写入开销，也没有写入漏洞，并且最重要的一点是不需要NVRAM硬件。ZFS 偏爱廉价磁盘。
但由于廉价磁盘容易出现故障，因此 ZFS 提供了磁盘清理功能。就像 ECC 内存清理一样，其理念是读取所有数据以检测潜在错误，而这些错误仍是可更正的。清理操作将遍历整个存储池，以读取每个块的每个副本，根据其 256 位校验和对其进行验证，并在必要时进行修复。所有这些操作都是在存储池运行和使用过程中进行的。
独一无二的可伸缩性
ZFS 文件系统的一个关键设计要素是可伸缩性。该文件系统本身是 128 位的，所允许的存储空间是 256 quadrillion zettabyte (256x1015 ZB)。所有元数据都是动态分配的，因此在首次创建时无需预先分配 inode，否则就会限制文件系统的可伸缩性。所有算法在编写时都考虑到了可伸缩性。目录最多可以包含 248(256 万亿)项，并且对于文件系统数或文件系统中可以包含的文件数不存在限制。
ZFS 快照快照是文件系统或卷的只读副本。可以快速而轻松地创建快照。最初，快照不会占用池中的任何附加磁盘空间。活动数据集中的数据更改时，快照通过继续引用旧数据来占用磁盘空间。因此，快照可防止将数据释放回池中。
简化的管理最重要的是其提供了一种极度简化的管理模型。通过使用分层文件系统布局、属性继承以及自动管理挂载点和 NFS 共享语义，ZFS 可轻松创建和管理文件系统，而无需使用多个命令或编辑配置文件。可以轻松设置配额或预留空间，启用或禁用压缩，或者通过单个命令管理许多文件系统的挂载点。您就可以检查或替换设备，而无需学习另外的一套卷管理命令。您可以发送和接收文件系统快照流。
ZFS 通过分层结构管理文件系统，该分层结构允许对属性(如配额、预留空间、压缩和挂载点)进行这一简化管理。在此模型中，文件系统是中央控制点。文件系统本身的开销非常小(相当于创建一个新目录)，因此鼓励您为每个用户、项目、工作区等创建一个文件系统。通过此设计，可定义细分的管理点。
存储池
不同于传统文件系统需要驻留于单独设备或者需要一个卷管理系统去使用一个以上的设备，ZFS创建在虚拟的，被称为“zpools”的存储池之上(存储池最早在AdvFS实现，并且加到后来的Btrfs)。每个存储池由若干虚拟设备(virtual devices，vdevs)组成。这些虚拟设备可以是原始磁盘，也可能是一个RAID1镜像设备，或是非标准RAID等级的多磁盘组。于是zpool上的文件系统可以使用这些虚拟设备的总存储容量。
可以使用磁盘限额以及设置磁盘预留空间来限制存储池中单个文件系统所占用的空间。
容量
ZFS是一个128位的文件系统，这意味着它能存储1800亿亿(18.4×1018)倍于当前64位文件系统的数据。ZFS的设计如此超前以至于这个极限就当前现实实际可能永远无法遇到。项目领导Bonwick曾说：“要填满一个128位的文件系统，将耗尽地球上所有存储设备。除非你拥有煮沸整个海洋的能量，不然你不可能将其填满。(Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans.)”
以下是ZFS的一些理论极限：
248—任意文件系统的快照数量(2 × 1014)
248—任何单独文件系统的文件数(2 × 1014)
16 exabytes (264 byte)—文件系统最大尺寸
16 exabytes (264 byte)—最大单个文件尺寸
16 exabytes (264 byte)—最大属性大小
128 Zettabytes (278 byte)—最大zpool大小
256—单个文件的属性数量(受ZFS文件数量的约束，实际为248)
256—单个目录的文件数(受ZFS文件数量的约束，实际为248)
264—单一zpool的设备数
264—系统的zpools数量
264—单一zpool的文件系统数量
作为对这些数字的感性认识，假设每秒钟创建1,000个新文件，达到ZFS文件数极限需要大约9,000年。
写时拷贝事务模型
ZFS使用一种写时拷贝事务模型技术。所有文件系统中的块指针都包括256位的能在读时被重新校验的关于目标块的校验和。含有活动数据的块从来不被覆盖；而是分配一个新块，并把修改过的数据写在新块上。所有与该块相关的元数据块都被重新读、分配和重写。为了减少该过程的开销，多次读写更新被归纳为一个事件组，并且在必要的时候使用日志来同步写操作。
利用写时拷贝使ZFS的快照和事物功能的实现变得更简单和自然，快照功能更灵活。缺点是，COW使碎片化问题更加严重，对于顺序写生成的大文件，如果以后随机的对其中的一部分进行了更改，那么这个文件在硬盘上的物理地址就变得不再连续，未来的顺序读会变得性能比较差。
快照与克隆
ZFS使用写时拷贝技术的一个优势在于，写新数据时，包含旧数据的块被保留着，提供了一个可以被保留的文件系统的快照版本。由于ZFS在读写操作中已经存储了所有构建快照的数据，所以快照的创建非常快。而且由于任何文件的修改都是在文件系统和它的快照之间共享的，所以ZFS的快照也是空间优化的。
可写快照("克隆")也可以被创建。结果就是两个独立的文件系统共享一些列的块。当任何一个克隆版本的文件系统被改变时，新的数据块为了反映这些改变而创建，但是不管有多少克隆版本的存在，未改变的块仍然在其他的克隆版本中共享。
动态条带化
ZFS能动态条带化所有设备以最大化吞吐量。当额外的设备被加入到zpool中的时候，条带宽度会自动扩展以包含这些设备。这使得存储池中的所有磁盘都被用到，同时负载被平摊到所有的磁盘上。
可变块尺寸
ZFS使用可变大小的块，最大可至128KB。现有的代码允许管理员调整最大块大小，这在大块效果不好的时候有用。未来也许能做到自动调整适合工作量的块大小。
ZFS的可变大小的块与BtrFS和Ext4的extent不同。在ZFS中，在一个文件中所有数据块的逻辑长度必须是相同的，不同文件之间的块大小可以不同，因此ZFS可以用直接映射(direct map)的方式(同ufs/ffs/ext2/ext3)来来搜索间接块的数据指针数组(blkptr)。BtrFS和Ext4的extent方式在同一个文件中每个数据快的大小都可以不相同，因此需要用B+ Tree或者类B Tree的方式来组织间接块的数据。
虽然直接映射方式比B+ Tree的查找速度快，但是这种方式的缺点也非常明显，如：元数据开销过大、顺序IO的大文件性能不好、删除比较慢等等，因此在现代文件系统中映射方式逐渐被extent变长块取代。如果数据压缩(LZJB)被启用，可变块大小需要被用到。如果一个数据块可被压缩至一个更小的数据块，则小的数据块将使用更少的存储和提高吞吐量(代价是增加CPU压缩和解压缩的负担)。
轻量化文件系统创建
在ZFS中，存储池中文件系统的操作相比传统文件系统的卷管理更加便捷。创建ZFS文件系统或者改变一个ZFS文件系统的大小接近于传统技术中的管理目录而非管理卷。
参考链接
ZFS主页
Solaris ZFS 管理指南
ZFS的设计与开发由Sun公司的Jeff Bonwick所领导的一支团队完成。最早宣布于2004年9月14日，于2005年10月31日并入了Solaris开发的主干源代码。ZFS 文件系统是一种革新性的新文件系统，可从根本上改变文件系统的管理方式，并具有目前面市的其他任何文件系统所没有的功能和优点。ZFS 强健可靠、可伸缩、易于管理。
ZFS 使用存储池的概念来管理物理存储，以前文件系统是在单个物理设备的基础上构造的。为了利用多个设备和提供数据冗余性，引入了卷管理器的概念来提供单个设备的表示，以便无需修改文件系统即可利用多个设备。此设计增加了更多复杂性，并最终阻碍了特定文件系统的继续发展，因为这类文件系统无法控制数据在虚拟卷上的物理放置。
ZFS 可完全避免使用卷管理。ZFS 将设备聚集到存储池中，而不是强制要求创建虚拟卷。存储池说明了存储的物理特征(设备布局、数据冗余等)，并充当可以从其创建文件系统的任意数据存储库。文件系统不再仅限于单个设备，从而可与池中的所有文件系统共享磁盘空间。您不再需要预先确定文件系统的大小，因为文件系统会在分配给存储池的磁盘空间内自动增长。添加新存储器后，无需执行其他操作，池中的所有文件系统即可立即使用所增加的磁盘空间。在许多方面，存储池与虚拟内存系统相似：将一个内存 DIMM 加入系统时，操作系统并不强迫您运行命令来配置内存并将其指定给个别进程。系统中的所有进程都会自动使用所增加的内存。
ZFS 是事务性文件系统，这意味着文件系统状态在磁盘上始终是一致的。传统文件系统可就地覆写数据，这意味着如果系统断电(例如，在分配数据块到将其链接到目录中的时间段内断电)，则会使文件系统处于不一致状态。以前，此问题是通过使用fsck命令解决的。此命令负责检查并验证文件系统状态，并尝试在操作过程中修复任何不一致性。这种文件系统不一致问题曾给管理员造成巨大困扰，fsck命令并不保证能够解决所有可能的问题。最近文件系统引入了日志记录的概念。日志记录过程在单独的日志中记录操作，在系统发生崩溃时，可以安全地重放该日志。由于数据需要写入两次，因此该过程会引入不必要的开销，而且通常会导致一组新问题，例如在无法正确地重放日志时。
对于事务性文件系统，数据是使用写复制语义管理的。数据永远不会被覆写，并且任何操作序列会全部被提交或全部被忽略。因此文件系统绝对不会因意外断电或系统崩溃而被损坏。尽管最近写入的数据片段可能丢失，但是文件系统本身将始终是一致的。此外，只有在写入同步数据(使用O_DSYNC标志写入)后才返回，因此同步数据决不会丢失。
对于 ZFS，所有数据和元数据都通过用户可选择的校验和算法进行验证。提供校验和验证的传统文件系统出于卷管理层和传统文件系统设计的必要，会逐块执行此操作。在传统设计中，某些故障可能导致数据不正确但没有校验和错误，如向错误位置写入完整的块等。ZFS 校验和的存储方式可确保检测到这些故障并可以正常地从其中进行恢复。所有校验和验证与数据恢复都是在文件系统层 执行的，并且对应用程序是透明的。
此外，ZFS 还会提供自我修复数据。ZFS 支持存储池具有各种级别的数据冗余性。检测到坏的数据块时，ZFS 会从另一个冗余副本中提取正确的数据，而且会用正确的数据替换错误的数据。
ZFS引入了一个新的数据复制模型，称为RAID-Z。它与RAID-5 类似，但采用可变条带宽度来消除RAID-5 写入漏洞(即由于数据和奇偶校验更新之间出现意外断电而导致条带损坏)。所有RAID-Z 写操作都是完整条带化写操作。这样，既没有读取-修改-写入开销，也没有写入漏洞，并且最重要的一点是不需要NVRAM硬件。ZFS 偏爱廉价磁盘。
但由于廉价磁盘容易出现故障，因此 ZFS 提供了磁盘清理功能。就像 ECC 内存清理一样，其理念是读取所有数据以检测潜在错误，而这些错误仍是可更正的。清理操作将遍历整个存储池，以读取每个块的每个副本，根据其 256 位校验和对其进行验证，并在必要时进行修复。所有这些操作都是在存储池运行和使用过程中进行的。
独一无二的可伸缩性
ZFS 文件系统的一个关键设计要素是可伸缩性。该文件系统本身是 128 位的，所允许的存储空间是 256 quadrillion zettabyte (256x1015 ZB)。所有元数据都是动态分配的，因此在首次创建时无需预先分配 inode，否则就会限制文件系统的可伸缩性。所有算法在编写时都考虑到了可伸缩性。目录最多可以包含 248(256 万亿)项，并且对于文件系统数或文件系统中可以包含的文件数不存在限制。
ZFS 快照快照是文件系统或卷的只读副本。可以快速而轻松地创建快照。最初，快照不会占用池中的任何附加磁盘空间。活动数据集中的数据更改时，快照通过继续引用旧数据来占用磁盘空间。因此，快照可防止将数据释放回池中。
简化的管理最重要的是其提供了一种极度简化的管理模型。通过使用分层文件系统布局、属性继承以及自动管理挂载点和 NFS 共享语义，ZFS 可轻松创建和管理文件系统，而无需使用多个命令或编辑配置文件。可以轻松设置配额或预留空间，启用或禁用压缩，或者通过单个命令管理许多文件系统的挂载点。您就可以检查或替换设备，而无需学习另外的一套卷管理命令。您可以发送和接收文件系统快照流。
ZFS 通过分层结构管理文件系统，该分层结构允许对属性(如配额、预留空间、压缩和挂载点)进行这一简化管理。在此模型中，文件系统是中央控制点。文件系统本身的开销非常小(相当于创建一个新目录)，因此鼓励您为每个用户、项目、工作区等创建一个文件系统。通过此设计，可定义细分的管理点。
存储池
不同于传统文件系统需要驻留于单独设备或者需要一个卷管理系统去使用一个以上的设备，ZFS创建在虚拟的，被称为“zpools”的存储池之上(存储池最早在AdvFS实现，并且加到后来的Btrfs)。每个存储池由若干虚拟设备(virtual devices，vdevs)组成。这些虚拟设备可以是原始磁盘，也可能是一个RAID1镜像设备，或是非标准RAID等级的多磁盘组。于是zpool上的文件系统可以使用这些虚拟设备的总存储容量。
可以使用磁盘限额以及设置磁盘预留空间来限制存储池中单个文件系统所占用的空间。
容量
ZFS是一个128位的文件系统，这意味着它能存储1800亿亿(18.4×1018)倍于当前64位文件系统的数据。ZFS的设计如此超前以至于这个极限就当前现实实际可能永远无法遇到。项目领导Bonwick曾说：“要填满一个128位的文件系统，将耗尽地球上所有存储设备。除非你拥有煮沸整个海洋的能量，不然你不可能将其填满。(Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans.)”
以下是ZFS的一些理论极限：
248—任意文件系统的快照数量(2 × 1014)
248—任何单独文件系统的文件数(2 × 1014)
16 exabytes (264 byte)—文件系统最大尺寸
16 exabytes (264 byte)—最大单个文件尺寸
16 exabytes (264 byte)—最大属性大小
128 Zettabytes (278 byte)—最大zpool大小
256—单个文件的属性数量(受ZFS文件数量的约束，实际为248)
256—单个目录的文件数(受ZFS文件数量的约束，实际为248)
264—单一zpool的设备数
264—系统的zpools数量
264—单一zpool的文件系统数量
作为对这些数字的感性认识，假设每秒钟创建1,000个新文件，达到ZFS文件数极限需要大约9,000年。
写时拷贝事务模型
ZFS使用一种写时拷贝事务模型技术。所有文件系统中的块指针都包括256位的能在读时被重新校验的关于目标块的校验和。含有活动数据的块从来不被覆盖；而是分配一个新块，并把修改过的数据写在新块上。所有与该块相关的元数据块都被重新读、分配和重写。为了减少该过程的开销，多次读写更新被归纳为一个事件组，并且在必要的时候使用日志来同步写操作。
利用写时拷贝使ZFS的快照和事物功能的实现变得更简单和自然，快照功能更灵活。缺点是，COW使碎片化问题更加严重，对于顺序写生成的大文件，如果以后随机的对其中的一部分进行了更改，那么这个文件在硬盘上的物理地址就变得不再连续，未来的顺序读会变得性能比较差。
快照与克隆
ZFS使用写时拷贝技术的一个优势在于，写新数据时，包含旧数据的块被保留着，提供了一个可以被保留的文件系统的快照版本。由于ZFS在读写操作中已经存储了所有构建快照的数据，所以快照的创建非常快。而且由于任何文件的修改都是在文件系统和它的快照之间共享的，所以ZFS的快照也是空间优化的。
可写快照("克隆")也可以被创建。结果就是两个独立的文件系统共享一些列的块。当任何一个克隆版本的文件系统被改变时，新的数据块为了反映这些改变而创建，但是不管有多少克隆版本的存在，未改变的块仍然在其他的克隆版本中共享。
动态条带化
ZFS能动态条带化所有设备以最大化吞吐量。当额外的设备被加入到zpool中的时候，条带宽度会自动扩展以包含这些设备。这使得存储池中的所有磁盘都被用到，同时负载被平摊到所有的磁盘上。
可变块尺寸
ZFS使用可变大小的块，最大可至128KB。现有的代码允许管理员调整最大块大小，这在大块效果不好的时候有用。未来也许能做到自动调整适合工作量的块大小。
ZFS的可变大小的块与BtrFS和Ext4的extent不同。在ZFS中，在一个文件中所有数据块的逻辑长度必须是相同的，不同文件之间的块大小可以不同，因此ZFS可以用直接映射(direct map)的方式(同ufs/ffs/ext2/ext3)来来搜索间接块的数据指针数组(blkptr)。BtrFS和Ext4的extent方式在同一个文件中每个数据快的大小都可以不相同，因此需要用B+ Tree或者类B Tree的方式来组织间接块的数据。
虽然直接映射方式比B+ Tree的查找速度快，但是这种方式的缺点也非常明显，如：元数据开销过大、顺序IO的大文件性能不好、删除比较慢等等，因此在现代文件系统中映射方式逐渐被extent变长块取代。如果数据压缩(LZJB)被启用，可变块大小需要被用到。如果一个数据块可被压缩至一个更小的数据块，则小的数据块将使用更少的存储和提高吞吐量(代价是增加CPU压缩和解压缩的负担)。
轻量化文件系统创建
在ZFS中，存储池中文件系统的操作相比传统文件系统的卷管理更加便捷。创建ZFS文件系统或者改变一个ZFS文件系统的大小接近于传统技术中的管理目录而非管理卷。
参考链接
ZFS主页
Solaris ZFS 管理指南