簡單的說
ZFS 適合大型的 storage, 而 BtrFS 只適合 1~4 個 HD 的 storage. (目前不建議 RAID5/6) 除非使用 kernel 4.2 的版本 (就目前使用 4.2 kernel的比例是不到 5%, 而且所有市面上的NAS 都還在使用 3.19以下的 Kernel)
原因如下:
BtrFS 只能支援 RAID 1, 1+0, 5 & 6, 其中 Raid 5&6 還算是 Alpha 階段, 下面是 btrfs 官網的說明:
"Parity RAID appeared in 3.9, and was considered experimental until 3.19, when recovery code to deal with bitrot/checksum errors was introduced. See RAID56 for more details. " **experimental = alpha.
BtrFS 強過 ZFS 的地方
1. BtrFS 可以輕鬆擴充 HD 以及容量, 譬如使用 3TB 的RAID1, 可以輕鬆的擴充到 6TB的RAID1, 而 ZFS 的 vDEV 模式並不適合更換硬碟擴充, 光是要 resilver 的時間就太誇張了, ZFS 是採取增加新的 vDEV (但是舊的 vDEV 是無法移除). 以實際面來說, 如果是大型的 storage 伺服器, 碰到儲存空間不夠時, 大部分的做法是買一台新的來慢慢做資料移轉 (或是舊的成為 second storage, 而新的成為 primary storage 使用), 比較少 storage administrator 心臟夠大顆, 來玩 storage server 的 live migration 擴充 (因為在 rebuild/resiliver 過程是資料 hd 最危險的時候), 但是以家用的 NAS, RAID 1 可以擴充, 或是從 RAID1 變成 RAID5 是很方便以及經濟的模式, 但是以企業的角度來說, 風險還是太大了.
2. 未來性. btrFS 未來一片光明, 太多大廠全力投入 btrFS 的開發讓它更完整, 穩定以及強大, 相對來說 ZFS 的邪惡繼父 Oracle 很糟糕, 再來就是收留 ZFS 的孤兒院 OpenZFS fundation 目前還沒有閃亮的人才如 bitcoin 的 Satoshi Nakamoto 可以給 ZFS 一個光明的未來在開源軟體群組中發展.
ZFS 強過 BtrFS 的地方
1. 效能. ZFS 可以使用 SSD cache 但是 btrFS 的 bcache (插件) 目前還是 alpha 階段, 同時官網目前註明這部分是 btrFS 目前需要重點發展的地方 (細節 https://bcache.evilpiepirate.org/) 目前是無人負責這個項目, 從官網的角度 https://btrfs.wiki.kernel.org/index.php/Project_ideas#dm_cache_or_bcache_like_cache_e.g._on_a_SSD
2. 壓縮. ZFS 支援 LZ4 壓縮, 這是非常重要的功能, 因為它搭配上 zfs 的 ssd cache 後, 間接把所有的 random write 都變成了 sequential write, 所以也造成 zfs 寫入速度非常快.
3. 大容量, 適合8顆以上 HD 的 storage, 而且越多顆效能越快, 其 raidZ3(raid7) 或是多個 raid1+0 組合模式, 可以讓 storage administrator 在效能, 容量空間, 以及 穩定安全性抉擇一個最好的平衡模式. 譬如, 如果 storage server 是 12顆 HD, 大部分的 administrator 會做成 6組 RAID 1, 然後以 stripe 模式 (raid 0) 達到最快的性能, 以及資料安全性的平衡, (因為如果使用 RAIDZ2/RAID6 效能會很糟, 同時資料遺失風險偏高, 兩個 HD 就有資料全毀的風險, hot spare 是很糟糕的模式, 因為 rebuild 過程中, 風險更高)
結論: ZFS 在未來 3~5年的時間內 (以及過去的5年), 還是這個地球上最強大的檔案格式, 它目前面對的競爭對手有 btrFS 以及 reFS (微軟的), 上述的優點就是為什麼 Qnap 這次推出的 伺服器等級的 NAS 是選擇 ZFS 而不是 btrFS, 而 Synology 在 1~4 bay 的家用 NAS 推用 btrFS. (真的還是不要在 btrFS 上面跑 raid5/6 目前)
補充:透過p大了解到 synology 是透過 lvm 下面運行 btrfs, 這個模式把 btrfs 處理 raid 的功能交給了 lvm. 但是其效能全部受限到 lvm 框架下, 以及 btrfs 的 online expanding/migration 目前是被封印中,而是透過 lvm 來運作 online expanding/migration. 這樣子的做法是優先檔案的安全性而犧牲部分效能(犧牲多少效能,目前沒有人做出過任何的比較,簡單猜測 10%~30%都有可能)。 再來 synology 的 SSD cache 是使用 lvm 專屬的 dm-cache 而非 btrfs 原生的 bcache, 這部分的對於使用 btrfs 是完全沒有特別多的效能增加,因為 kernel 在這部分的特效是無法開啟的。謝謝 p 大讓我理解 synology 的架構以及模式。
EluSiOn wrote:
簡單的說ZFS 適...(恕刪)
on Synology NAS 採用 ext4 or btrfs 在效能上是否有很大的差異? 這部份似乎也沒有人特別去測過, 但依現在手上使用的 ds415+ 不管採用 ext4 or btrfs 似乎也感受不到效能上有很大的差別, 大檔讀寫也都是在 100MB/s 以上. 所以到底由 btrfs 自己 handle raw partition 來得有效率? 還是架構在 lvm 上面? 這是未知的. 因為 benchmark 你必須去測整個流程, 而不是單看到直接對 raw partition 操作比較有效率, 就忽略了其他環節.
同樣的道理, ZFS 它在 file system 裡面自己 implement ssd cache 機置在裡面, 但並不能依此就認為 ZFS file system performance 優於其他 file system, 這是立足點的不同, 你必須考量整體的架構, 在 kernel 上面加上 ssd cache 機置, 搭配不同的 file system 再去和 ZFS 比較, 至少這樣的比較才會有意義.
FB: Pctine
其實一個 sata3 channel 極限值是 550mb/s, 但是如果是使用傳統 HD 時,因為受到 rotary motor 先天限制,以效能較強的 wd black 只有 120mb/s, wd re 150mb/s~180mb/s. 但是當在跑 Raid 1+0 的時候,其硬體效能極限值應該是接近 550 mb/s。
所以在 1 gbps 的 eth network下,這些極限的數據值都不會被挑戰到,而這個就是為什麼沒有人在做這部分的 benchmark.
當大型 storage server 在運作時,可以參考 ibm 所說的 lvm 的限制,https://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.osdevice/logstorlimits.htm。請以 default 值為標準,因為絕大部分 Linux os 的 kernel 都是 以 default 值去優化。也就是 35 tb 這個容量極限值是很輕易被挑戰到的。
最後就是目前 lvm/lvm2 只是 32/64 bit, 而 btrfs 是一個 128 bit 的 file system, 所以以企業 enterprise storage admin 的角度來看,這樣等於是封印太多 btrfs 的 128 bit 的優點。所以這個也就是為什麼在 idc 機房不會有這樣子的軟體架構模式,所以不會看見 ibm/hp/dell 採取 synology 的方式。也造就為什麼沒有人會更加去做這部分的測試。最後也是因為 btrfs 的部分功能還是在 alpha stage, 所以在企業使用上比例真的太低,因為心臟不夠大顆。(主要的 core 功能是 production ready)
但是上述的問題,在家用的 nas 市場都不會碰上,所以 synology 的做法並無錯誤。而在 enterprise storage 這部分,軟體架構是越簡化越好,所有資源運行最好都是以原生模式直接對 kernel 為主。所以 emc, nimba 這些 enterprise storage 廠商它們的驅動只能運行在他們的硬體上, 確認它們的 file system 以及架構是運行在最底層。如果使用者在它們的架構的上層要運行 lvm 或 ext4 都不會影響到它們服務器底層的效能以及穩定。
而 zfs 是原生的 128 bit file system, 它連自己 mounting 的模式都是透過自己的 tools, 而不使用 /etc/fstab 來確認一切都是由它控制。而 zfs 強過 emc 或是 nimba storage 的地方是,它採取開放架構,沒有特殊硬體要求,可以在 usb thumb drive 帶著走,隨便插入的 伺服器/PC 都可以變成一個 zfs storage.
再來就是目前 10gbe 開始慢慢進入家用市場,越來越多主板上是 10gbe (雖然目前都還是在高端主板電競主板),這是為了 迎接 4k 媒體的時代,這部分的普及化大約會在 3~5年內。(現在連 wan 都開始 1gbps 發展了,所以 lan 朝 10gbps 是必然的)這段時間剛好是給 btrfs 追上這部分不足的空間。
pctine wrote:
這篇論文的作者應該是...(恕刪)
那篇很出名,因為是 Google search 的第一個 result, 引起廣泛的討論。 最後大家(reddit/sth) 得到的結論如下
1. 這個是一個大學未畢業學生的功課,無實際實施經驗。也從未知道 storage server 怎麼調校。
2. 所有的 os 版本,kernel 版本,benchmark test 版本都給了,但是 btrfs/zfs 的 kernel driver 版本卻沒有給,讓大家一頭霧水。也不知道 dedup/lz4 是否開啟, 猜測是 dedup 應該沒有開(正確)但是 lz4 好像是關閉的,因為 database 測試那邊的數據推測的。( 給 database 使用的 hd 通常 storage admin 會關 lz4, 讓 db server 原生處理)
3. 他的測試跟之前很多人的測試是抵觸的,也無法複製出來相同的 result. 特別是 btrfs 可以大贏特贏 ext4。
4. 很多人都很難成功安裝 oracle 10g on Ubuntu 14.04,但是他測試的卻是使用 oracle 9i,這個是最令人費解的地方。
後來大部分的人是根據以下這個測試 http://www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-and-lvm-with-kvm-a-storage-performance-comparison.html?limitstart=0 zfs vs ext4 vs xfs 為依據。
原因如下
1. storage test 大家很重視 iops 以及 latency, 大學生的測試報告只有 mb/s.
2. 大家還是沒有看到 btrfs 的版本, 但是 ext4 的數據跟大家測試的數據相符,所以只看 zfs 的數據,而 btfs 只是參考,有部分測試大家覺得它的 tools crash 了。
最後有一個很實際的問題這些 test 無法顯示出來,就是 btrfs pool 跟 zfs pool 使用一陣子後,當數據 1/3滿或是半滿時,都有效能下降的問題,有很多人受不了改回去使用 xfs/ext4. 而這部分沒有辦法拿實際使用中的 data pool 去跑 benchmark (已經一堆 vm 在使用了),大部分的 storage admin 3~5年都會 destroy 原本的 pool, 再建立一次,把數據導回,效能下降的問題就感受不明顯。有人懷疑是 CoW table 有問題,重建後 re-index,性能就恢復了,也有人懷疑是 ssd trim 的問題,但是使用 NVMe ssd 的 pool 也有類似的情況。
vgbjack wrote:
BTRFS可能比較適合一般群眾
ZFS不能R1 變R2的確是點麻煩
online expansion 跟 online balancing/auto loading 兩點是 btrfs 的強項, 都是強過 ZFS. ZFS 新增加 vDEV (新增 HD) 後, 並不會把所有硬碟上的資料重新整理平均分配, 而這點 btrfs 做的到. 但是 LVM 下面的 btrfs 也是沒有這個 online balancing/auto loading.
Synology 的 online expansion RAID1 -> RAID5 是使用 lvm 模式而不是使用 btrfs 模式.
thi wrote:
是喔,有這種問題,效能下降大約多少?
很難說... 因為一旦 storage server 在使用中, 幾乎沒有 idle 的時間可以提供做測試, 我個人有感覺每次重建後, 整個 pool 都會快上 40% 以上, 但是這個數字只是在做 backup 以及一些 data moving 的所需要的時間的感覺. 不過本來 storage server 每三年最好做一次大檢查, 畢竟很多 HD 保固都只有 3年 (少數 5年) 但是都還是會怕. 所以就當作車子每三年~五年一次進廠大維修就好了. (重新 rebuild 一次 storage server 大概要 2個小時, 安裝以及設定, 數據導回需要 10個小時使用 40gbps, 所以只要以第二台 storage server 獨立支撐 12個小時就好) 我的建議是, 越多小型的storage server 越好, 使用 distribute file system (glusterfs 或是 ceph) 來確保資料及時同步 (以 server 的模式做 raid1/mirror ) 或是 兩份 data set 分散到 三台 storage server ( 以 server 的模式做 raid5) 這樣子是最保險的. 我非常不建議使用一台龐大的 storage server, 上面儲存個 1pb~4pb 的數據, 那樣子的龐然大物, 根本是完全不能接受一點點的 downtime 跟風險係數太高了, 一個風扇, 一個 sas expansion panel, 一顆電容出問題, 就可以讓整台 4 pb 的 storage server 下線, 所以現在都不在走 scale up 的模式, 而盡量使用 scale out 的模式 (不要把所有的蛋都放在一個籃子裡的概念)
Oneplus 8 Pro•
Thinkpad T480s•
PVE6+OMV4+NextCloud
QNAP 廠房的主管亦補充,所有進行燒機的 NAS 都會裝上 Enterprise 系列的硬碟機去進行測試,而且每隔一段時間就會替換新的硬碟機,確保速度測試部份不會受到硬碟機老化所影響,而個別附帶硬碟機發售的 NAS 例如 TAS-x68 系列,就會在燒機完成後換上新的硬碟機再進行包裝。
三星 SSD 降速門 http://www.expreview.com/36572.html
Oneplus 8 Pro•
Thinkpad T480s•
PVE6+OMV4+NextCloud
關閉廣告