这篇文章主要为大家展示了“SOLARIS ZFS文件系统的示例分析”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“SOLARIS ZFS文件系统的示例分析”这篇文章吧。
创新互联建站长期为近千家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为铜山企业提供专业的网站设计、成都网站制作，铜山网站改版等技术服务。拥有10余年丰富建站经验和众多成功案例,为您定制开发。
ZFS是SUN推出的世界上第一个128位的文件系统，这意味着它能存储1800亿亿(18.4 × 10^1 ８)倍于当前64位文件系统的数据。ZFS的设计如此超前以至于这个极限就当前现实际可能永远无法遇到。据说：“要填满一个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.)”[1]
以下是ZFS的一些理论极限：
* 2^4８ — 任意文件系统的快照数量 (2 × 10^14)
* 2^4８ — 任何单独文件系统的文件数 (2 × 10^14)
* 16 exabytes (2^64 byte) — 文件系统最大尺寸
* 16 exabytes (2^64 byte) — 最大单个文件尺寸
* 16 exabytes (2^64 byte) — 最大属性大小
* 3 × 10^23 petabytes (2^78 byte) — 最大zpool大小
* 2^56 — 单个文件的属性数量(受ZFS文件数量的约束，实际为2^4 ８)
* 2^56 — 单个目录的文件数(受ZFS文件数量的约束，实际为2^4 ８)
* 2^64 — 单一zpool的设备数
* 2^64 — 系统的zpools数量
* 2^64 — 单一zpool的文件系统数量
作为对这些数字的感性认识，假设每秒钟创建1,000个新文件，达到ZFS文件数极限需要大约9,000年。
在辩解填满ZFS与煮沸海洋的关系时，Bonwick写到：
尽管我们都希望摩尔定律永远延续，但是量子力学给定了任何物理设备上计算速率（computation rate）与信息量的理论极限。举例而言，一个质量为1公斤，体积为1升的物体，每秒至多在10^31位信息 上进行10^51次运算。[参考 Seth Lloyd, "Ultimate physical limits to computation（计算的终极物理限制）." Nature 406, 1047-1054 (2000)]。一个完全的128位存储池将包含2^12８ 个块 = 2^137 字节 = 2^140 位；应此，保存这些数据位至少需要(2^140 位) / (10^31 位/公斤) = 1360亿公斤的物质。
补充：
使用ZFS的十条理由
1. 再也不需要fsck, scandisk
不管你是在用Linux，UNIX还是Windows，相信大家都有过类似的体会：当系统意外断电或者非法关机，系统重起后发现文件系统有 inconsistent的问题，这时 候就需要fsck或者scandisk 来修复，这段时间是非常耗时而且最后不一定能够修复成功。更糟糕的是，如果这是一台服务器需要做fsck的时候，只能offline（下线），而且现有应用往往都是大硬盘，相应fsck修复时间也很长，这对许多使用该服务器的用户来说几乎不能忍受的。而使用ZFS后大家可以彻底抛弃fsck这种工具，因为 ZFS是一个基于COW（Copy on Write）机制的文件系统。COW是不会对硬盘上现有的文件进行重写，保证所有硬盘上的文件都是有效的。所以不会有这种inconsistent的概念，自然就不需要这种工具了。
2. 管理简单
ZFS作为一个全新的文件系统，全面抛弃传统File System + Volume Manager + Storage的架构，所有的存储设备是通过ZFS Pool进行管理，只要把各种存储设备加 入同一个ZFS Pool，大家就可以轻松的在这个ZFS Pool管理配置文件系统。大家再也不用牢记各种专业概念，各种命令newfs, metinit及各种Volume Manager的用法。在ZFS中我们只需要两个命令，zpool(针 对ZFS Pool管理)和zfs(针对ZFS文件系统的管理)，就可以轻松管理128位的文件系统。举个例子，我们经常会遇到系统数据增长过快，现有存储容量不够，需要添加硬盘，如果依照传统的Volume Manager管理方式，那我们需要预先要考虑很多现有因素，还要预先根据应用计算出需要配置的各种参数。在ZFS情况下，我们的系统管理员可以彻底解放，再也不需要这种人为的复杂考虑和计算，我们可以把这些交给ZFS，因为ZFS Pool会自动调节，动态适应需求。我们只需一个简单的命令为这个ZFS Pool加入新的硬盘就可以了：
zpool add zfs_pool mirror c4t0d0 c5t0d0
基于这个动态调节的ZFS Pool之上的所有的文件系统就可以立即使用到这个新的硬盘，并且会自动的选择最优化的参数。
而且ZFS同时也提供图形化的管理界面。
3. 没有任何容量限制
ZFS（Zettabyte File System）文件系统就如其名字所预示，可以提供真正的海量存储，在现实中几乎不可能遇到容量问题。在现有的64位kernel（内核）下，它可以容纳达到16 Exabytes(264)大小的单个文件，可以使用264个存储设备，可以创建264个文件系统。
4. 完全保证 数据 的正确和完整
由于ZFS所有的数据操作都是基于Transaction（事务），一组相应的操作会被ZFS解析为一个事务操作，事务的操作就代表着一组操作要么一起失败，要么一起成功。而且如前所说，ZFS对 所有的操作是基于COW（Copy on Write）， 从而保证设备上的数据始终都是有效的，再也不会因为系统崩溃或者意外掉电导致数据文件的inconsistent。
还有一种潜在威胁数据的可能是来自于硬件设备的问题，比如磁盘，RAID卡的硬件问题或者驱动bug。现有文件系统通常遇到这个问题，往往只是简单的把错误数据直接交给上层应用，通常我们把这个问题称作 Silent Data Corruption。而在ZFS中，对所有数据不管是用户数据还是文件系统自身的metadata数据都进行256位的Checksum（校验），当ZFS在提交数据时会进行校验，彻底杜绝这种Silent Data Corruption情况。
5. 提供优异 性能和扩展性
和传统File System + Volume Manager + Storage架构不同，ZFS则是直接基于存储设备提供所有的功能，因此有自己独有的创新特性，性能自然非比寻常。
* Dynamic Striping vs. Static Striping
由于ZFS是基于COW和一个全局动态的ZFS Pool，任何一次写 操作，都是对一块新数据块（Block）的一次写操作。ZFS从ZFS Pool中动态挑选出一个最优的设备，并且以一个transaction（事务）线性写入，充分有效地利用了现有设备的带宽，我们把这个特性称为 Dynamic Striping。而相对应的Static Striping则是传统文件系统所使用的方式，Static Striping需要管理员预先对这组Stripe进行正确地计算人为设置，而且如果加入新的设备则需要再次人为的计算和设置，更为严重的是如果人为计算错误，则会直接影响系统的性能。而在使用Dynamic Striping这种特性之后，我们根本不需要人为介入，ZFS会自动调整，智能的为你提供最佳的设备，最快的操作方式。
* 支持多种 大小的数据块（Multiple Block Size）
ZFS支持多种大小的数据块定义，从512字节到1M字节。和传统文件系统往往都是固定大小数据块不同，ZFS则是可以动态的根据不同 大小的文件进行计算，动态的选择最佳的数据块。
因为不同大小数据块，直接影响到实际使用硬盘容量和读取速度。如果使用较小的数据块，存储文件所导致的碎片则较少，读写小文件更快一些，但是会导致需要创建更多的 metadata，读写大文件则会更费时。如果使用较大的数据块，使用的metadata较少，更利于读写大文件，但是会导致更多的碎片。ZFS根据实际调查现有文件使用的情况，分析出一个选择数据块大小的算法，动态的根据实际文件大小确定最佳的数据块。所以ZFS是非常智能的，在不需要系统管理员介入，就可以得到一个自我调优的结果。当然ZFS也支持用户对单个文件或者整个文件系统所使用的数据块大小的自定义设置。
* 智能预读取（Intelligent Prefetch）
多数的操作系统都有这种将数据预先读取的功能，而ZFS则是建立在文件系统上直接提供的一种更加智能的数据预读取功能。它不仅可以智能地识别出多种读取模式， 进行提前读取数据，而且可以对每个读取数据流进行这种预读取智能识别，这个对许多流媒体提供者来说是件非常好的事情。
在扩展性上，和现有文件系统多是基于一个受限的静态模型不同，ZFS是采用ZFS Pool这个动态概念，它的metadata也是动态，并且读写操作都是可并行的，并且具有优先级概念，所以即使在大数据量，多设备的情况下仍可以保证性能的线性增长。
6. 自我修复功能
* ZFS Mirror 和 RAID-Z
传统的硬盘Mirror及RAID 4，RAID 5阵列方式都会遇到前面提到过的问题：Silent Data Corruption。如果发生了某块硬盘物理问题导致数据错误，现有的Mirror，包括RAID 4，RAID 5阵列会默默地把这个错误数据提交给上层应用。如果这个错误发生在Metadata中，则会直接导致系统的Panic。而且还有一种更为严重的情况是：在 RAID 4和RAID 5阵列中，如果系统正在计算Parity数值，并再次写入新数据和新Parity值的时候发生断电，那么整个阵列的所有存储的数据都毫无意义了。
在ZFS中则提出了相对应的ZFS Mirror和RAID-Z方式，它在负责读取数据的时候会自动和256位校验码进行校验，会主动发现这种Silent Data Corruption，然后通过相应的Mirror硬盘或者通过RAID-Z阵列中其他硬盘得到正确的数据返回给上层应用，并且同时自动修复原硬盘的 Data Corruption 。
* Fault Manager
在Solaris 10中，包含 一个ZFS诊断引擎和Solaris的 Fault Manager（这也是Solaris 10的另一个新特性）交互，可以实时地诊断分析并且报告ZFS Pool和存储设备的错误，用户可以通过Fault Manager及时得到一个非常友善的消息。这个诊断引擎虽然不会采取主动的行为去修复或者解决问题，但是会在消息中提示系统管理员可采取的动作。类似下面一个ZFS报错消息，其中REC-ACTION就是建议采取的动作：
SUNW-MSG-ID: ZFS-8000-D3, TYPE: Fault, VER: 1, SEVERITY: Major
EVENT-TIME: Fri Mar 10 11:09:06 MST 2006
PLATFORM: SUNW,Ultra-60, CSN: -, HOSTNAME: neo
SOURCE: zfs-diagnosis, REV: 1.0
EVENT-ID: b55ee13b-cd74-4dff-8aff-ad575c372ef8
DESC: A ZFS device failed. Refer to http://sun.com/msg/ZFS-8000-D3 for more information.
AUTO-RESPONSE: No automated response will occur.
IMPACT: Fault tolerance of the pool maybe compromised.
REC-ACTION: Run ’zpool status -x’ and replace the bad device.
7. 安全
在安全上，ZFS支持类似NT风格NFSv4版的ACL（读取控制列表）。而且前面所提到的256位验证码，用户可选择多种验证方式，包括SHA-256验证算法，从而在物理存储单元级别上保证数据的安全性。
8. 超强功能
ZFS作为“最后一个文件系统”，涵盖了基本的文件系统和Volume管理的功能，同时一并提供许多企业级别的超强功能：Quota(配额)， Reservation(预留), Compression(压 缩)， Snapshot(快照)，Clone（克隆）。并且速度非常快。有了这个文件系统，大家再也不需要任何Volume Manager了。
9. 兼容性
ZFS是一个完全兼容POSIX规范的文件系统，所以处于上层的应用程序是完全不受影响。ZFS也提供一个Emulated Volume模块，可以把任何一个ZFS文件系统作为普通的块设备使用。同时ZFS也可以使用基于Volume Manager构建的Volume作为存储设备单 元。这样在不需要修改应用程序，不修改已有文件系统下，给了大家最大的自由度去获得ZFS提供的各种特性。
10. 开源
ZFS是Sun Microsystems公司作为OpenSolaris的一个开源项目运作并且完全免费使用，点击这里(http: //www.opensolaris.org/os/community/zfs/source/) 可以直接浏览到ZFS的代码。这就代表着我们不仅同时可以享受商业公司的高质量，也可以获得开源模式的优点。
虽然目前只有Solaris支持该文件系统，但是这种开源的模式必定会促进更多基于ZFS的应用。现在已经有国外开发者正在将ZFS移植到Linux和 Mac OS上来。如果想要体验一下ZFS，由于目前它和Solaris 10绑定在一起，所以需要下载最新版的Solaris 10 6/06 。 |
以上是“SOLARIS ZFS文件系统的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！
网站名称：SOLARISZFS文件系统的示例分析
本文路径：
http://cdkjz.cn/article/pghdjo.html
