網上收集：http://www.ixpub.net/thread-766068-1-1.html
txg (transaction groups)
應用的檔案寫操作一般分為兩種，同步寫和普通寫操作。同步寫是指寫操作必須物理地寫到
儲存介質上才能返回給應用，通常這種情況發生在open檔案時指定了o_dsync或o_sync
屬性，以及呼叫fsync()等；普通寫操作是指寫操作寫到檔案系統cache裡即可返回給應用，通
常以普通方式開啟檔案後的write()，fwrite()操作都是這種操作。txg (transaction groups)則是
負責管理如何將檔案系統cache（arc）裡的資料同步到磁碟上的機制。
對於寫進檔案系統cache裡的每乙個資料都會被編入乙個txg，通常情況下每隔5秒鐘或檔案
系統cache裡有太多髒資料（待寫入磁碟的資料達到arc的一半），當前txg裡的所有資料
會被同步到磁碟，同時啟動下乙個txg。每乙個zfs pool同時最多會有3個txg，分別處於
3種狀態：open, quiescing, syncing。當txg不能在5秒內把資料同步到磁碟上時將會影響
open txg，從而引起應用寫操作的阻塞。這個現象叫做寫抑制（throttling）。
當前的solaris 版本（solaris 10 8/07）對寫抑制的控制不是非常好，當進行密集的寫操作並且
arc較大、磁碟系統較慢時容易使txg同步資料的時間非常長，發生throttling從而使應用的
後續寫操作的響應時間非常長。在新的opensolaris發行包裡，這個問題已經有了很大的改進，
zfs會監測arc接收資料的速度和arc資料同步到磁碟上的速度，並自動調整arc接收數
據的速度。另外arc髒資料的大小限制改為1/8物理記憶體。通過這種控制可以使應用的寫操
作響應時間更為均勻穩定。
zil (zfs intent log)
對於同步寫操作，zfs為系統中每乙個zfs檔案系統維護乙個zil(zfs intent log)。同步寫操
作的資料會先寫入zil，並且會把磁碟的write cache的資料同步到磁碟上，然後應用的寫操作
返回。當檔案提交命令發生時，zfs會把zil裡該檔案的資料同步到磁碟上。
預設情況下，zil是在zfs儲存池中動態分配的。某些同步寫操作（比如資料庫的聯機重做日
志或nfs commit）如果響應時間慢將會極大影響效能。為了不使zil受其它i/o操作的影
響，可以考慮採用乙個專門的快速裝置如nvram，ssd(solid state disk)等做zil，以下命令
為zfs儲存池新增專用的zil:
zpool add log
另外，由於每次同步寫操作會使zfs把磁碟 write cache的資料同步到磁碟上，對於san的存
儲，頻繁地flush cache會嚴重影響效能並且是不必要的。這個問題在opensolaris裡已經得到
解決，解決辦法是讓裝置驅動程式向儲存系統發出適當的命令選項，從而使儲存系統可以忽
略從non-volatile cache同步到磁碟的請求。前提是儲存系統可以識別驅動程式發出的命令選項。
i/o scheduler and priorities
預設情況下，zfs會限制每乙個它能看到的儲存池裡的裝置的i/o佇列長度為35，並且通常讀
操作的優先順序高於寫操作。這種做法的目的是保證較好的i/o service time。
根據實際的應用需求和儲存裝置的不同，可能需要調整i/o佇列的大小。比如為了得到更好地
響應時間，在/etc/system裡設定：set zfs:zfs_vdev_max_pending = 10
prefetch (file level and device level)
和其它檔案系統一樣，zfs也有預讀的功能。zfs檔案系統的預讀分為file-level和devicelevel
。file-level的預讀是指zfs可以檢測到檔案讀取的模式，預先讀入檔案的後續部分從而減少i/o
操作以提高效能。對於大併發量的針對不同檔案的讀操作，file-level的預讀通常不會帶來好處，
可以把預讀關掉：在/etc/system裡設定：set zfs:zfs_prefetch_disable = 1 。
device-level的預讀是指在讀取資料塊時，會讀取裝置相鄰的資料，假定相鄰資料隨後會被用
到。device-level的預讀有時會讀入不需要的資料反而會影響效能，在新的opensolaris發行包
裡，device-level的預讀只預讀metadata。
raidz and raidz2
zfs提供了類似傳統raid5和raid6的功能，分別叫做raidz和raidz2。但raidz的實
現與傳統raid5有很大不同：raidz的所有寫操作都是full-stripe write，結合zfs的copyon-
write和checksum的機制，可以保證資料的一致性，無需像傳統的raid5那樣需要昂貴的
nvram來保證條帶資料的一致性。
raidz的stripe size是完全動態的。每乙個檔案系統塊(record)在儲存時會平均分配到raidz
group裡的所有磁碟上，並以512位元組為單位。例如，假設乙個4kb的檔案，如果儲存在4+1
的raidz group，則4kb的資料會分散到4個磁碟上，每個磁碟上儲存1kb。因此乙個
raidz group裡的裝置不應過多，否則會影響讀操作的效能。一般建議為3~9個。raidz比
較適合大檔案的順序讀寫。
由於raidz在設計上的特殊性，在資料恢復時需要通過metadata來恢復，要遍歷整個pool。
當某塊磁碟出現故障時，raidz重建的速度與metadata的數量有關。當有大量metadata資料
時，比如大量snapshots或pool裡的檔案數量龐大，資料重建的速度會較慢。在這種情況下，
可以考慮建立多個pool。當然，對乙個很空的檔案系統，raidz的重建時間會很短。
ZFS檔案系統
zfs zettabyte file system 源自於sun microsystems為solaris作業系統開發的檔案系統。zfs是乙個具有高儲存容量 檔案系統與卷管理概念整合 嶄新的磁碟邏輯結構的輕量級檔案系統，同時也是乙個便捷的儲存池管理系統。zfs是乙個使用common developm...
ZFS檔案系統
本文 zfs zettabyte file system 源自於sun microsystems為solaris作業系統開發的檔案系統。zfs是乙個具有高儲存容量 檔案系統與卷管理概念整合 嶄新的磁碟邏輯結構的輕量級檔案系統，同時也是乙個便捷的儲存池管理系統。zfs是乙個使用common devel...
ZFS檔案系統介紹和掛載
zfs檔案系統介紹和掛載 一 zfs檔案系統介紹 1.1簡介 zfs檔案系統的英文名稱為zettabyte file system,也叫動態檔案系統 dynamic file system 是第乙個128位檔案系統。最初是由sun公司為solaris 10作業系統開發的檔案系統。作為opensola...