ZFS最佳实践指南

ZFS最佳实践指南

（注：本文目前的写做背景是Solaris 10 以及 OpenSolaris，但一样对FreeBSD具备参考做用，

• 原文请参见：http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide）
• 其它参考：
  • Ubuntu上使用ZFS（Zettabyte File System）
  • 提高ZFS性能的10个简便方法
• 性能测试
  • Ubuntu测试-使用phoronix-test-suite
  • 六款优秀的 Linux 基准测试工具

1 ZFS管理事项

1.1 ZFS存储池建议

本节描述了配置ZFS存储池的通用建议。

1.1.1 系统

• 请使用64位内核运行ZFS。

1.1.1.1 内存与交换空间

• 推荐使用1GB以上的内存。

• 装载每一个ZFS文件系统约耗费64KB的内存空间。在一个存在上千个ZFS文件系统的系统上，咱们建议您为包括快照在内的每1000个所装载的文件系统多分配1GB额外内存。并对为其所带来的更长的引导时间有所准备。

• 由于ZFS在内核保留内存中缓存数据，因此内核的大小极可能会比使用其它文件系统时要大。您能够配置额外的基于磁盘的交换空间（Swap Space）来解决系统内存限制的这一问题。您可使用物理内存的大小做为额外所需的交换空间的大小的上限。但不管如何，您都应该监控交换空间的使用状况来肯定是否交换正在进行。

• 如条件容许，请不要将交换空间与ZFS文件系统所使用分区（slice）放在同一磁盘上。保证交换区域同ZFS文件系统分开。最佳策略是提供足够多的内存使您的系统不常使用交换设备。

• 更多的内存使用事项，请见：内存与动态重构（Dynamic Reconfiguration）建议。

1.1.2 存储池

• 如条件容许，架设每一个系统的存储池请使用整个磁盘。

• 对于生产系统，考虑使用整个磁盘而不是分区（slice），有以下理由：

  • 容许ZFS开启磁盘的写缓存。但若是您使用有永久性写缓存的磁盘阵列，那么这一问题并不突出，做为虚拟设备的分区也能够受益于盘阵的写缓存。

  • 若在分区上包含有ZFS和UFS文件系统，则对待替换坏盘的恢复步骤则变得更加复杂。

  • 若在其余分区上还含有UFS文件系统，则ZFS存储池（和其下的磁盘），使用zpool import和export功能不易被迁移至他处。

  • 通常而言，维护分区会增长管理成本。应经过简化您的存储池结构来下降管理成本。

• 对于全部生产环境，请配置ZFS以便其能够修复数据不一致问题。使用ZFS的冗余技术，如raidz，raidz2，镜像，或者副本>1，不须要考虑在其下的存储设备上的RAID级别的实现。应用此类冗余技术，其下的存储设备到主机链接的故障均可以被ZFS发现并修复。

• 请不要用48个设备来建立一个raidz，raidz2或者镜像配置的逻辑设备。请参见后面的冗余配置的示例。

• 在建立复制的存储池配置中，请使用多个控制器达到了减小硬件故障和提升性能的做用，例如：

# zpool create tank mirror c1t0d0 c2t0d0

• 配置热备来加速硬件故障时的恢复速度。对于高数据损失平均时间（Mean Time To Data Loss，MTTDL ，译者注）的环境来讲热备是相当重要的。例：

# zpool create tank mirror c1t0d0 c2t0d0 spare c1t1d0 c2t1d0

• 请按期运行zpool scrub来肯定数据完整性问题。若您的驱动器是消费级质量的驱动器，则请考虑将scrub的进度以周为单位进行；如果数据中心级质量的驱动器，则请考虑以月为单位。

• 对模拟磁盘驱动器（SSD）的电子存储设备，ZFS也能够工做得很好。因为每字节成本相对较高，您可在这类存储池上开启压缩属性。

1.1.2.1 简单的或条带化的存储池限制

简单的或条带化的存储池有一些应被考虑的限制。

• 可经过两种方式实现对存储空间的扩充：

  • 添加另外一磁盘以扩展条带（stripe）。这也会提高存储池的性能，由于更多的设备能够被并发使用。注意：当前的ZFS实现是，一旦添加，虚拟设备则不能被移除。

# zpool add tank c2t2d0

• 用更大的虚拟设备替代现有的虚拟设备

# zpool replace tank c0t2d0 c2t2d0

• ZFS能允许多种设备故障。

  • 对于简单的存储池来讲，元数据（metadata）是双重冗余的，但数据并不冗余。

  • 您可使用ZFS copies属性为数据设定冗余级别。

  • 若文件块不能被彻底读取且没有冗余，ZFS会告诉您哪些文件受其影响。

• 对于简单存储池而言，替换故障硬盘既须要访问旧有设备也须要访问新设备，这是为了可以将旧数据放到新设备上。

# zpool replace tank c0t2d0         ### 错误：不能再建立数据由于不存在冗余

# zpool replace tank c0t2d0 c2t2d0  ### ok

1.1.3 多个存储池于同一系统

• 在ZFS存储池中的资源容许不一样的文件系统在不一样的时候受益于全部资源。这一策略可大幅提升在存储池内的任一文件系统性能。

• 若一些做业量须要更多的可预测的性能特色，那么您可考虑将做业量分给不一样的存储池。

• 例如，Oracle日志记录器性能很是依赖于I/O响应时间，咱们能够经过将这样的负载保持于一个单独的有最低响应时间的小存储池来实现。

1.1.3 根存储池建议

若您正在使用ZFS根文件系统（root file system），请保持根存储池（即存储池的数据集是被分配给根文件系统的）与用于数据的存储池分开。 关于这一策略存在几个理由：

• 在您不会想要放到数据存储池的根存储池上存在一些限制（与数据池相比，根存储池存在一些限制）。镜像存储池与单磁盘存储池是支持的。可是，RAID-Z或有一块磁盘以上的非复制存储池不行。（注：在 FreeBSD 上，若是不使用 ZFS 引导系统，而只是用它做为根文件系统，则没有这种限制）

• 数据存储池能够是体系结构无关的。这对在SPARC和Intel之间移动数据存储池是有好处的。根存储池是很是依赖于特定的体系结构的。

• 一般，咱们认为将系统的“个性”同其数据分开是个不错的主意。这样的话，您就能够改变一个而不用改变其余的。

给咱们当前分配的做为单独的文件系统（例如：根，/usr和/var）配置不一样的存储池根本不合理。这或许都不是一个所支持的配置。对于这些目录有单独的数据集却是可能，但只能在同一个存储池中。 关于ZFS和SVM镜像的根内容，请参见UFS/SVM节。

1.2 存储池性能事项

1.2.1 通用存储池性能事项

• 为了更佳的性能，请使用单个磁盘或至少只是由少数盘组成的LUN。经过使ZFS于LUN的设置中更可见，ZFS可以提供更佳的I/O调度决策。

• 依赖于做业量，当前的ZFS的实现相比于其余的基于分页的文件系统能够不时的使更多I/O被请求。若是吞吐量正在流向存储，由iostat来观察，其已接近存储和主机之间的信道链路的容量，调小zfs recordsize属性通常能提升性能。这种调整是动态的，但只是对新文件建立有影响。已存在的文件仍是保持其原有的recordsize。

• 调节recordsize对顺序类型的负载没有帮助。调节recordsize的方式是针对使用随机少许的读写来密集的处理大文件的状况来提高做业量。

• 请参考ZFS与数据库建议

• 当前，存储池的性能可能会由于存储池很满且文件系统被频繁的更新而降低，如繁忙的邮件服务器。在这些状况下，请保持存储池的空间在80%如下以维持存储池性能。

1.2.1.1 单独日志设备

ZFS intent log（ZIL，ZFS意图日志）符合POSIX的同步事务（synchronous transactions）的要求。例如，数据库从系统调用返回时经常须要其事务要在稳定的存储设备上。在默认状况下，intent log从主存储池中分配块。然而，若使用独立的intent log设备，其可能会得到更佳的性能，像NVRAM或专用磁盘。请肯定是否一个单独的日志设备适合您的环境：

• 实现单独的日志设备（log device）所体现的任何性能提高都依赖于设备类型、存储池的硬件配置、和应用的做业量。

• 日志设备能够是不复制或镜像的，但RAIDZ不被日志设备所支持。

• 日志设备的最小的尺寸同存储池中的最小设备尺寸相同，也是64MB。存储于日志设备上的实际数据量可能相对较少。当日志事务（系统调用）被提交时，日志块被释放。

• 最大的日志设备的尺寸应大概是物理内存的1/2，由于那是能被保存的实际数据的最大量。例如，若是一个有16GB物理内存的系统，其最大的日志设备应是8G。

• 对于日志设置信息和日志性能信息，请参见以下Blog：slog_blog_or_blogging_on来查看关于单独日志设备的总说明，参见《Solaris ZFS管理指南》（《Solaris ZFS Administration Guide》）。

1.2.1.2 内存与动态重构（Dynamic Reconfiguration）建议

ZFS的自适应置换高速缓存（Adaptive Replacement Cache，ARC）试图使用最多的系统可用内存来缓存文件系统数据。默认是使用除了1GB以上的全部的物理内存。当内存压迫性增加时，ARC会放弃内存。 请在以下情形时考虑限制最大ARC内存的使用范围：

• 当有已知数量的内存老是被应用程序请求时。数据库经常属于这一类。

• 在支持内存板动态重构的平台上，以防止ZFS将渐大的内核占据到全部的内存板上。

• 请求大内存分页的系统也会受益于对ZFS缓存的限制，这可将大的分页分解为基本分页。

• 最后，若系统上还运行有其余非ZFS文件系统，除了ZFS以外，最好再留一些空闲内存给那些文件系统做为缓存。

这些限制内存使用范围的方式被认为会使ARC不能缓存更多的文件系统数据，这可能会对性能有所影响。 总之，若内存既没被ZFS使用也没被其余系统组件使用，限制ARC则是浪费资源的。注意非ZFS文件系统一般仍会设法使用系统的空闲内存来缓存数据。 调节ARC的详细信息，请参考以下段落： http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Limiting_the_ARC_Cache

1.2.2 RAID-Z配置要求及建议

一个以N块X大小和P个奇偶校验磁盘的RAID-Z配置能够拥有大约（N-P）×X的字节并能承受P个设备故障而不破坏数据完整性。

• 配置单奇偶校验的RAID-Z须要3块磁盘起（2+1） 。

• 配置双奇偶校验的RAID-Z2须要4块硬盘起（2+2） 。

• 配置三奇偶校验的RAID-Z3须要6块起（3+3）。

• 推荐的每组磁盘数在3至9之间。若是您有更多的磁盘，请使用多个组。

有都市传说认为 ZFS 应配置为 (N+P），其中N为2的整数次方幂而P为与对应 RAID-Z/RAID-Z2/RAID-Z3 的奇偶校验盘数量，而且对性能影响很大。这种说法是没有科学根据的。

1.2.3 镜像配置建议

• 在设备数上没有可实际影响的限制

• 在SUN Fire X4500服务器上，请勿用48个设备建立一个镜像。请考虑建立24个两两设备的镜像。这一配置将磁盘容量缩小了1/2，但多至24个磁盘或每个镜像上1个磁盘均可以无端障的被失去。

• 若您须要更佳的数据保护，三路镜像可在MTTDL上比双路镜像有显著提高。但再升为四路（或更高的）镜像，则只是在数据保护上提供有限的改进。因此若三路镜像还不够，请考虑其余的数据保护方式。

1.2.3 我应该配置RAID-Z、RAID-Z2仍是镜像存储池？

一般须要考虑的是您的目标是最大磁盘空间仍是最优性能

• RAID-Z配置可得到最大磁盘空间，且当被写入和读取大块（large chunk）（128KB或更大）的数据时一般都表现不错。

• RAID-Z2配置提供了卓越的数据可用性且其具有同RAID-Z类似的特色。相比于RAID-Z或双路镜像，RAID-Z2具备显著更佳的数据损失平均时间（MTTDL）。

• 镜像配置消耗更多的磁盘空间，但一般其具有更好的随机少许的读取能力。

• 若是您的I/O是大量的、顺序的、或是写频繁的，则ZFS的I/O调度器会将其聚集起来，以这样一种方式您会得到很高效的磁盘使用而不论数据的复制模型。

为得到更好的性能，在大量的、不可缓存的、随机读取负载上，镜像配置要显著的胜于RAID-Z配置。 关于RAIDZ所需注意事项的更多信息，请参考以下blog： WHEN TO (AND NOT TO) USE RAID-Z

1.2.4 RAID-Z配置举例

例如在Tunmper上的RAID-Z配置，将c3t0和c3t4（磁盘0和1）镜像做为您的根存储池，剩下的46块可用磁盘用于用户数据。以下的raidz2配置举例说明了如何配置剩下的46块盘：

• 5×(7+2)，1个热备，17.5 TB

• 4×(9+2)，2个热备，18.0 TB

• 6×(5+2)，4个热备，15.0 TB

1.3 ZFS迁移事项

1.3.1 ZFS与分区技术（Zone）

当在安装有区域（zone）的Solaris系统上使用ZFS数据集（dataset）时请牢记以下几点：

• 当前您还不能给区域关联ZFS快照。

• 在Solaris 10发行版中对于全局区域（global zone）的根路径（root path）或非全局区域（non-global zone）请不要使用ZFS文件系统。

• 您能够在Solaris Express发行版中使用ZFS做为区域的根路径，但请牢记修补或升级这些区域是不被支持的。

想要了解区域使用ZFS的更多信息，请参见以下FAQ条目： [1]（http://opensolaris.org/os/community/zones/faq/#cfg_zfsboot）

1.3.2 UFS/SVM

当下，您不能在当前的Solaris 10发行版中使用ZFS为根文件系统。若是您想使用基于镜像备份的根文件系统，您须要使用SVM将包含系统软件（root，/usr，/var，等等）的分区（slice）进行镜像。其余全部存储均可以使用ZFS来进行管理。请不要使用ZFS和SVM重叠存储。例如，您可使用磁盘或分区做为SVM卷或者ZFS存储池的一部分。但请不要在相同的磁盘或者分区上使用SVM和ZFS配置。 当将数据从UFS文件系统迁移至ZFS文件系统时，请参考以下实践：

• 取消共享（unshare）现有的UFS文件系统

• 从以前的挂载点（mount points）取消挂载现有的UFS文件系统

• 挂载UFS文件系统至临时非共享挂载点

• 互起rsync实例，迁移UFS数据至ZFS文件系统

• 在新的ZFS文件系统上设置挂载点和sharenfs属性

1.3.2.1 UFS/SVM 交互

ZFS 能够不须要任何额外的卷管理软件即能很好工做。 若是您须要额外级别的卷管理，ZFS要求能将连续的1至4MB的逻辑块映射至连续的物理块上。若能够达到这一要求，咱们就能以ZFS的功能使用卷了。

1.3.3 VxVM/FS

2 常规ZFS管理信息

• ZFS只管理在线数据。

• 关于配置存储池的更多信息，请参见，ZFS存储池建议。

• ZFS文件系统当被建立时便被自动挂载。

• ZFS 文件系统不须要经过修改/etc/vfstab被挂载。

• 当前，ZFS不提供像ufsdump和ufsrestore命令这样的全面的备份/恢复工具。然而您可使用zfs send和 zfs receive命令来捕获ZFS数据流。您也可使用ufsrestore命令来恢复UFS数据至ZFS文件系统。

• 更多的ZFS管理任务，请参看zfs.1m和zpool.1m联机手册。更详细的文档，请参考《Solaris ZFS管理指南》（《Solaris ZFS Administration Guide》）。询问ZFS问题，请加入opensolaris/zfs讨论组。

3 应用服务器使用ZFS事项

3.1 ZFS NFS 服务器实践

请参考以下课程所述之UFS至ZFS迁移经验：

• 存在用户主目录（home directory）被重命名但其并为被取消挂载。当新的主目录也被共享时，NFS却继续服务于旧主目录。

• 切勿混淆UFS的目录与在一样文件系统层面上的ZFS文件系统，这会搞乱管理和维护。

• 切勿混淆基于NFS原始共享的ZFS文件系统（NFS legacy shared ZFS file systems）与基于ZFS的NFS共享的文件系统（ZFS NFS shared file systems），由于这样的模型很难以维护。请使用基于ZFS的NFS共享的文件系统（译者注，即便用ZFS自带的sharenfs方式而不要使用NFS本身的通用的原始共享方式）。

• ZFS能够由sharenfs文件系统属性与zfs share命令共享。例如：

# zfs set sharenfs=on export/home

• 该语法自动共享文件系统。若ZFS文件系统须要被共享，请使用zfs share命令。例如：

# zfs share export/home

关于跨NFS的ZFS的性能信息，请参阅ZFS与NFS服务器性能。

3.1.1 基于ZFS的NFS服务器优点

• NFSv4风格的ACL（访问控制列表）在ZFS文件系统上可用且ACL信息可自动经过NFS可用。

• ZFS快照能够经过NFSv4可用，这样挂载主目录的NFS就能够访问其.snapshot目录了。

3.2 ZFS主目录服务器实践

当规划您的ZFS主目录（home directory）时，请参考以下实践：

• 每一个用户配置一个文件系统

• 使用磁盘配额和保留以管理用户磁盘空间

• 使用快照备份用户主目录

当从UFS文件系统向ZFS文件系统迁移数据时，请参考以下实践：

• 取消（Unshare）现有UFS文件系统的共享

• 从以前的挂载点（mount points）取消挂载现有的UFS文件系统

• 挂载UFS文件系统至临时非共享挂载点

• 互起rsync实例，迁移UFS数据至ZFS文件系统

• 在新的ZFS文件系统上设置挂载点和sharenfs属性

请参阅 #ZFS_NFS_Server_Practices section for additional tips on sharing ZFS home directories over NFS.

3.2.1 ZFS主目录服务器的好处

• 得益于ZFS的高容量架构，可使其可以处理许多小文件与许多用户。

• 用户主目录（home directory）的额外空间能够经过添加更多的设备到存储池而轻松扩大。

• ZFS磁盘配额是一种便捷的管理主目录空间的方式。

• 使用ZFS inheritance属性可将属性应用于许多文件系统。

3.3 ZFS邮件/新闻服务器

3.4 ZFS软件开发服务器

3.5 ZFS备份还原建议

3.5.1 使用ZFS快照

• 可使用ZFS快照做为备份用户主目录的快速便捷方式。例如，以下语法会建立在/tank/home中的全部主目录的递归的快照。

# zfs snapshot -r tank/home@monday

• 您能够建立滚动快照用来管理快照副本。要了解更多信息，请参考Blog：Rolling Snapshots Made Easy。

• 您可使用zfs send和zfs receive命令存档快照至更持久的存储上。

• 您能够建立增量快照流（请看“zfs send -i”语法）。

• zfs send 和 receive命令不是企业级备份解决方案。

3.5.2 使用ZFS于AVS

Sun StorageTek Availability Suite（AVS），是一套Solaris的基于主机的数据服务，其同Veritas VVR（Volume Replicator）和Flashsnap（point-in-time copy，时间点副本）产品相似，当前在Solaris Express发行版中可用。 SNDR（Sun StorEdge Network Data Replicator）同ZFS send和recv功能不一样，其具有的是固定时间（time-fixed）的复制功能。例如，您能够得到一时间点快照，复制它，或是基于先前快照的差异进行复制。AVS II与SNDR功能的结合，还容许您进行固定时间复制。其余模式的AVS SNDR复制功能容许您得到CDP（Continuous Data Replication，持续数据复制）。ZFS当前并无这类功能。 关于AVS的更多信息，请参见OpenSolaris AVS项目。 请在此查看AVS/ZFS演示。

3.5.3 使用ZFS于企业备份解决方案

• Sun StorEdge Enterprise Backup Software（Legato Networker 7.3.2）产品可全面备份和恢复包括ACL的ZFS文件。

• Symantec NetBackup 6.5产品可彻底备份与恢复ZFS文件，包括ACL，虽然其兼容性矩阵（Compatibility Matrix）（2007年9月） 很意外的没有说起ZFS。

• IBM的TSM产品也可被用于备份ZFS文件。可是具体的支持性不是很是清晰。基于TSM支持的文档在IBM的站点，ZFS的ACL可被TSM client 5.3支持。已被确认（SUN内部）可在5.4.1.2上正常工做。

tsm> q file /opt/SUNWexplo/output # Last Incr Date Type File Space Name — ————– —- —————

1   08/13/07   09:18:03   ZFS     /opt/SUNWexplo/output
                           ^
                           |__正确的文件系统类型

• ZFS快照能够在有快照的文件系统中经过.zfs目录访问。请配置您的备份产品跳过这些目录。

关于ZFS的企业级备份解决方案问题的最新信息，请参见ZFS FAQ 为了能充分利用ZFS的功能，如快照，来提升备份和还原的进度，ndmp服务会在Solaris（首先在OpenSolaris）中发行。根据这些附加功能，企业级备份解决方案能够经过充分利用快照来提高对大存储库的数据保护。

3.6 ZFS与数据库建议

关于正在进行的ZFS和数据库性能测试的信息，请参看zfs_and_databases。还可参见ZFS for Databases

概要说明

• 若是数据库针对I/O使用固定磁盘的块或记录尺寸，请将ZFS的recordsize属性设成与数据库一致。您能够在每一个文件系统上作这一操做，即便是共享一个存储池的多个文件系统。

• 因为其copy-on-write设计，调小ZFS的recordsize是一种以牺牲批处理报告查询为代价而提升OLTP（On-Line Transaction Processing，联机事务处理）性能的方式。

• ZFS校验存于磁盘上的每一个块（block）。这减轻了数据库层面上对校验数据的须要和额外的时间。若校验由ZFS代替了数据库的，全部的差别均可以在数据返回给应用程序以前被捕获和修正。ZFS在数据库上的性能是很是快的活动目标。保持对Solaris发行版的更新很是重要。

截至2007年7月，以下功能会对数据库性能产生影响：

• ZFS 放出多至35个并发I/O至每一个顶级设备，且这能够致使服务的时间延长。

• ZFS对每一输入块进行一些多至64K的低级预取操做，这样作可令存储带宽饱和。详情请参见6437054号Bug以及这篇blog。

• 使用8K的预取并用5到10个并发I/O来帮助一些数据库的负载。对于调节这些值的作法请参看ZFS Evil Tuning Guide。这种调节须要有望在将来发行版中去除。

Oracle事项

• 为获得更好的OLTP性能，请将ZFS的recordsize同Oracle的db_block_size相匹配。

• 请在混合的批处理和OLTP中关注批处理报告

• 对Oracle日志请以默认的128K记录尺寸使用单独的文件系统。

• 在SXCE Build 68发行版中，您能够为ZFS intent log（ZIL）使用单独的设备建立ZFS存储池。更多信息，请参见separate intent log。请不要将ZFS intent log设备同Oracle日志相混淆。

• 最小化Oracle日志响应时间，以期在整个事务过程当中只是惟一的I/O，这每每是咱们所但愿的。就SAN存储阵列而言，Oracle日志响应时间应是接近写至SAN缓存的响应时间的，所以没有必要在数据空间和日志空间中来划分主轴（spindle）资源：单一的存储池操做。但对于在JBOD存储上的Oracle来讲，其已被看到使用被分出来的一套主轴（不受制于读或写的竞争）能够有助于日志的响应时间。这反过来能够对一些工做量有帮助，如这类在存储级别上有高写读比的操做。

PostgreSQL

• 限定ZFS ARC已在内存与动态重构（Dynamic Reconfiguration）建议中描述

• 关于对日志使用单独存储池，请参看上述Oracle事项。

• 请设置ZFS recordsize=8K（注意：请在任何数据文件的建立以前作这一设置！）

• 从日志存储池中初始化数据库，以后为每个数据库建立一个新的表分区（tablespace）指向数据存储池

MySQL

参考：A look at MySQL on ZFS

• InnoDB:

• 限定ZFS ARC已在内存与动态重构（Dynamic Reconfiguration）建议中描述

• 关于对日志使用单独存储池，请参看上述Oracle事项。

• 请设置ZFS recordsize=8K|16K（注意：请在任何数据文件的建立以前作这一设置！）

• 以后请对数据和日志使用不一样的路径（在mysql.conf）中设置

• MyISAM:

• 限定ZFS ARC已在内存与动态重构（Dynamic Reconfiguration）建议中描述

• 请为日志（WAL）建立独立的intent log。若您没有该功能（即您运行在Solaris 10发行版），那么请建立至少两个存储池，一个存数据，一个存日志（WAL）

• 关于对日志使用单独存储池，请参看上述Oracle事项。

• 请设置ZFS recordsize=8K|16K（注意：请在任何数据文件的建立以前作这一设置！）

请参阅一些在PostgreSQL和MySQL中用db_STRESS性能测试得到的真实结果。

3.7 ZFS与复合存储事项

• 某些存储子系统会将数据暂放在固态内存设备，如存储阵列上的NVRAM，容许其以很是低的响应时间响应写操做。这些内存设备一般被认为是稳定的存储，在必定意义上其能幸免于掉电或其余类的崩溃。在关键时刻，ZFS是不知道该内存存储器的持久性的，而且要求该存储器的数据同步至磁盘。若这些存储器真的被肯定为是稳定的，存储系统应被配置为忽略这些来自ZFS的请求。

3.8 驱动问题

4 ZFS管理/观察工具

5 虚拟化事项

5.1 ZFS与虚拟带库（VTL）

虚拟带库解决方案是经过对模拟磁带、磁带驱动器和带库的使用而出现的一种硬件与软件的结合体。虚拟带库被用于备份/存档系统，被定位于用来减小硬件和软件的成本。 虚拟带库是大量磁盘空间的吞噬者，咱们相信ZFS将容许其更有效和安全的管理大量的、在线磁盘空间。

• Falconstor虚拟带库–该虚拟带库须要磁盘块设备来工做。其不使用外部文件系统。所以目前不能使用ZFS和Falconstor虚拟带库相结合的方法。

• Copan 虚拟带库–同上（Copan 使用 Falconstor 虚拟带库）。

• 来自BakBone的NetVault–该备份解决方案包括了虚拟带库功能，其已经在运行有ZFS的Thumper上测试过。

5.2 ZFS与VMWare

6 ZFS性能事项

对于基本系统、内存、存储池和副本建议，请参考以下章节：

• ZFS存储池建议

• 我应该配置RAID-Z、RAID-Z2仍是镜像存储池？

• Roch/Jim/Neel的Blog

6.1 ZFS与应用程序事项

6.1.1 ZFS与NFS服务器性能

配有ZFS的NFS，这被应用在许多不一样地方并未报有明显不足。不少人报告对性能表示失望，但这恐怕是将跨NFS的ZFS的性能同本地文件系统所比较了。众所周知相比于本地或直连的文件系统而言，提供NFS服务会明显下降速度。尤为是对于低线程并发的做业量而言。有一种危险的建立更优的跨NFS的ZFS的方式，是以牺牲数据完整性为代价设定内核变量zil_disable。该参数的设定并不被推荐。 请参考：ZFS与数据库建议。 关于跨NFS的ZFS性能的更多详细信息，请参见 zfs and nfs。

• Web 服务器

• 流做业量

6.2 ZFS文件系统的其余行为与使用误区

6.3 DTrace剖分（profile）以分类应用程序

6.4 性能优化

6.5 调节与策略设置

6.6 ZFS更多事项

• 压缩

• 校验和- 校验问题已被测量过，约1GHz的CPU能够校验500MB/sec的数据。

• RAID-Z

• 截至Solaris 10 11/06发行版时，校验和，压缩，和RAID-Z奇偶计算所有出如今线程同步存储池数据的上下文中。在重负载状况下，该线程可能成为性能瓶颈。在将来发行版中全部这类计算有望在并发线程中完成。经过修复了6460622号Bug以后，压缩问题已再也不是单线程，且会成为Solaris 10 8/07发行版的一部分。

6.7 可扩展性