推荐使用1GB以上的内存。
装载每个ZFS文件系统约耗费64KB的内存空间。在一个存在上千个ZFS文件系统的系统上，我们建议您为包括快照在内的每1000个所装载的文件系统多分配1GB额外内存。并对为其所带来的更长的引导时间有所准备。
因为ZFS在内核保留内存中缓存数据，所以内核的大小很可能会比使用其它文件系统时要大。您可以配置额外的基于磁盘的交换空间（Swap Space）来解决系统内存限制的这一问题。您可以使用物理内存的大小作为额外所需的交换空间的大小的上限。但无论如何，您都应该监控交换空间的使用情况来确定是否交换正在进行。
如条件允许，请不要将交换空间与ZFS文件系统所使用分区（slice）放在同一磁盘上。保证交换区域同ZFS文件系统分开。最佳策略是提供足够多的内存使您的系统不常使用交换设备。
更多的内存使用事项，请见：内存与动态重构（Dynamic Reconfiguration）建议。
对于所有生产环境，请配置ZFS以便其可以修复数据不一致问题。使用ZFS的冗余技术，如raidz，raidz2，镜像，或者副本>1，不需要考虑在其下的存储设备上的RAID级别的实现。应用此类冗余技术，其下的存储设备到主机连接的故障都可以被ZFS发现并修复。
请不要用48个设备来创建一个raidz，raidz2或者镜像配置的逻辑设备。请参见后面的冗余配置的示例。
在创建复制的存储池配置中，请使用多个控制器达到了减少硬件故障和提高性能的作用，例如：
# zpool create tank mirror c1t0d0 c2t0d0
# zpool create tank mirror c1t0d0 c2t0d0 spare c1t1d0 c2t1d0
简单的或条带化的存储池有一些应被考虑的限制。
# zpool add tank c2t2d0
# zpool replace tank c0t2d0 c2t2d0
ZFS能容许多种设备故障。
对于简单的存储池来说，元数据（metadata）是双重冗余的，但数据并不冗余。
您可以使用ZFS copies属性为数据设定冗余级别。
若文件块不能被完全读取且没有冗余，ZFS会告诉您哪些文件受其影响。
# zpool replace tank c0t2d0 ### 错误：不能再创建数据因为不存在冗余
# zpool replace tank c0t2d0 c2t2d0 ### ok
在ZFS存储池中的资源允许不同的文件系统在不同的时候受益于所有资源。这一策略可大幅提高在存储池内的任一文件系统性能。
若一些作业量需要更多的可预测的性能特点，那么您可考虑将作业量分给不同的存储池。
例如，Oracle日志记录器性能非常依赖于I/O响应时间，我们可以通过将这样的负载保持于一个单独的有最低响应时间的小存储池来实现。
若您正在使用ZFS根文件系统（root file system），请保持根存储池（即存储池的数据集是被分配给根文件系统的）与用于数据的存储池分开。
关于这一策略存在几个理由：
在您不会想要放到数据存储池的根存储池上存在一些限制（与数据池相比，根存储池存在一些限制）。镜像存储池与单磁盘存储池是支持的。但是，RAID-Z或有一块磁盘以上的非复制存储池不行。（注：在 FreeBSD 上，如果不使用 ZFS 引导系统，而只是用它作为根文件系统，则没有这种限制）
数据存储池可以是体系结构无关的。这对在SPARC和Intel之间移动数据存储池是有好处的。根存储池是非常依赖于特定的体系结构的。
通常，我们认为将系统的“个性”同其数据分开是个不错的主意。这样的话，您就可以改变一个而不用改变其他的。
给我们当前分配的作为单独的文件系统（例如：根，/usr和/var）配置不同的存储池根本不合理。这或许都不是一个所支持的配置。对于这些目录有单独的数据集倒是可能，但只能在同一个存储池中。
关于ZFS和SVM镜像的根内容，请参见UFS/SVM节。
为了更佳的性能，请使用单个磁盘或至少只是由少数盘组成的LUN。通过使ZFS于LUN的设置中更可见，ZFS能够提供更佳的I/O调度决策。
依赖于作业量，当前的ZFS的实现相比于其他的基于分页的文件系统可以不时的使更多I/O被请求。如果吞吐量正在流向存储，由iostat来观察，其已接近存储和主机之间的信道链路的容量，调小zfs recordsize属性一般能提高性能。这种调整是动态的，但只是对新文件创建有影响。已存在的文件还是保持其原有的recordsize。
调节recordsize对顺序类型的负载没有帮助。调节recordsize的方式是针对使用随机少量的读写来密集的处理大文件的情况来提升作业量。
请参考ZFS与数据库建议
当前，存储池的性能可能会因为存储池很满且文件系统被频繁的更新而下降，如繁忙的邮件服务器。在这些情况下，请保持存储池的空间在80%以下以维持存储池性能。
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》）。
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
一个以N块X大小和P个奇偶校验磁盘的RAID-Z配置可以拥有大约（N-P）×X的字节并能承受P个设备故障而不破坏数据完整性。
配置单奇偶校验的RAID-Z需要3块磁盘起（2+1）
配置双奇偶校验的RAID-Z需要5块硬盘起（3+2）
规律为（N+P），P=1（RAIDZ），P=2（RAIDZ2），N等于2，4，或8。
推荐的每组磁盘数在3至9之间。如果您有更多的磁盘，请使用多个组。
通常需要考虑的是您的目标是最大磁盘空间还是最优性能
为获得更好的性能，在大量的、不可缓存的、随机读取负载上，镜像配置要显著的胜于RAID-Z配置。
关于RAIDZ所需注意事项的更多信息，请参考如下blog：
WHEN TO (AND NOT TO) USE 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
当下，您不能在当前的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属性
ZFS 可以不需要任何额外的卷管理软件即能很好工作。
如果您需要额外级别的卷管理，ZFS要求能将连续的1至4MB的逻辑块映射至连续的物理块上。若可以达到这一要求，我们就能以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讨论组。
请参考如下课程所述之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 share export/home
关于跨NFS的ZFS的性能信息，请参阅ZFS与NFS服务器性能。
当规划您的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.
得益于ZFS的高容量架构，可以使其能够处理许多小文件与许多用户。
用户主目录（home directory）的额外空间可以通过添加更多的设备到存储池而轻松扩大。
ZFS磁盘配额是一种便捷的管理主目录空间的方式。
使用ZFS inheritance属性可将属性应用于许多文件系统。
# zfs snapshot -r tank/home@monday
您可以创建滚动快照用来管理快照副本。要了解更多信息，请参考Blog：Rolling Snapshots Made Easy。
您可以使用zfs send和zfs receive命令存档快照至更持久的存储上。
您可以创建增量快照流（请看“zfs send -i”语法）。
zfs send 和 receive命令不是企业级备份解决方案。
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演示。
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 FAQ
为了能充分利用ZFS的功能，如快照，来提高备份和还原的进度，ndmp服务会在Solaris（首先在OpenSolaris）中发行。根据这些附加功能，企业级备份解决方案可以通过充分利用快照来提升对大存储库的数据保护。
关于正在进行的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
InnoDB:
限定ZFS ARC已在内存与动态重构（Dynamic Reconfiguration）建议中描述
关于对日志使用单独存储池，请参看上述Oracle事项。
请设置ZFS recordsize=8K（注意：请在任何数据文件的创建之前做这一设置！）
之后请对数据和日志使用不同的路径（在mysql.conf）中设置
MyISAM:
限定ZFS ARC已在内存与动态重构（Dynamic Reconfiguration）建议中描述
请为日志（WAL）创建独立的intent log。若您没有该功能（即您运行在Solaris 10发行版），那么请创建至少两个存储池，一个存数据，一个存日志（WAL）
关于对日志使用单独存储池，请参看上述Oracle事项。
请设置ZFS recordsize=8K（注意：请在任何数据文件的创建之前做这一设置！）
请参阅一些在PostgreSQL和MySQL中用db_STRESS性能测试获得的真实结果。
虚拟带库解决方案是通过对模拟磁带、磁带驱动器和带库的使用而出现的一种硬件与软件的结合体。虚拟带库被用于备份/存档系统，被定位于用来减少硬件和软件的成本。
虚拟带库是大量磁盘空间的吞噬者，我们相信ZFS将允许其更有效和安全的管理大量的、在线磁盘空间。
Falconstor虚拟带库–该虚拟带库需要磁盘块设备来工作。其不使用外部文件系统。因此目前不能使用ZFS和Falconstor虚拟带库相结合的方法。
Copan 虚拟带库–同上（Copan 使用 Falconstor 虚拟带库）。
来自BakBone的NetVault–该备份解决方案包括了虚拟带库功能，其已经在运行有ZFS的Thumper上测试过。
对于基本系统、内存、存储池和副本建议，请参考如下章节：
配有ZFS的NFS，这被应用在许多不同地方并未报有明显不足。很多人报告对性能表示失望，但这恐怕是将跨NFS的ZFS的性能同本地文件系统所比较了。众所周知相比于本地或直连的文件系统而言，提供NFS服务会明显降低速度。尤其是对于低线程并发的作业量而言。有一种危险的创建更优的跨NFS的ZFS的方式，是以牺牲数据完整性为代价设定内核变量zil_disable。该参数的设定并不被推荐。
请参考：ZFS与数据库建议。
关于跨NFS的ZFS性能的更多详细信息，请参见 zfs and nfs。
压缩
校验和- 校验问题已被测量过，约1GHz的CPU可以校验500MB/sec的数据。
-
截至Solaris 10 11/06发行版时，校验和，压缩，和RAID-Z奇偶计算全部出现在线程同步存储池数据的上下文中。在重负载情况下，该线程可能成为性能瓶颈。在未来发行版中所有这类计算有望在并发线程中完成。通过修复了6460622号Bug之后，压缩问题已不再是单线程，且会成为Solaris 10 8/07发行版的一部分。