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發行版的一部分。

ZFS最佳實踐指南 頂 轉