vgbjack wrote:
他指的是linux 要run zfs 會有中介 fuse
ZFS on Linux 現在不用過 FUSE 囉，不過還是要一層 Solaris Porting Layer，memory management 是過這一層自己管的，之前測試的時候發現跟 linux/mm 的機制沒有接得很好，如果系統上還有其他應用會比較麻煩，不知道現再有沒有改善。
betoptic wrote:
就算在volume卸...(恕刪)
自己去看測試吧
https://ww還w.facebook.com/groups/nas.tw/permalink/10154534902678245/
https://www.facebook.com/groups/nas.tw/permalink/10154536137713245/
在這兩個人的測試, 不同的檔案格式 rebuild 在同一台主機上, 就是速度不同. 你就是空有理論沒有實作經驗的問題.
.
兩個人的測試 因為CPU 的效能不同結果產生不同的結果. 越低階的 CPU btrfs on LVM 比較快. 越高階的 CPU ext4 on LVM 速度比較快.
EluSiOn wrote:
不知道你的測試版本的 linux 是那一版本.
Ubuntu 16.04 LTS 已經是原生支援也沒有你說的問題. Centos 7 也可以使用 yum 安裝了. spl 最大目的是模擬 Solaris 的 kernel, 這邊在 0.6就很穩定了. 目前最新的版本是 0.6.5 然後馬上要 release 0.7了
或許這裡有點誤會，ZOL 的確已經是原生的 kernel module。我是指 ZOL#3085 和 SPL#388 這類 Linux 上會觸發 shrink slab 的行為，看起來問題還是沒解決。SPL 存在的目的是讓 ZFS 移植到 Linux/OSX 能夠有最少的修改，避免穩定性在移植的過程中下降，但也間接帶來一些先天的限制。整體上來講會比較建議還是在 FreeBSD/Solaris 上使用 ZFS。之前也曾經想把手上 ZFS 機器全都轉到 Linux 上，但測了一下 ZOL，還是乖乖留在 FreeBSD 上保險一點。
EluSiOn wrote:
自己去看測試吧 ht...(恕刪)
這些測試是在測試 rebuild 的時間不論誰快誰慢都是在10%以內，要照樓主的論點好像時間要一模一樣才能說 rebuild 時間跟檔案系統無關。
基本上測試本來就是有很多變因，嚴格的測試要做很多次取其平均，基本中學實驗常識應該都要有。
但是以初步的結果來看，LVM rebuild 時間跟上面是什麼檔案系統相關係數真的不太大。也就是樓主一直以 btrfs 在 LVM rebuild 的效能問題把它延伸為 data risk 問題，其實這個論點根本站不住腳。
BTRFS 跟 ext4 在 LVM rebuild 效能也許真的跟檔案系統有關，但是的確差異不大，因為效能主要還是跟底層 LVM raid 有關係。
綜觀全文，我覺得樓主是被 ineffective 這個字眼誤導了，這個其實是指 BTRFS 本身自己的 raid 5 的最佳化沒有被用到而已。
不過在公開論壇上，通常一般人就算證據再多，也很難承認自己之前的論點有誤，這邊我可以體諒樓主
EluSiOn wrote:
自己去看測試吧 https...(恕刪)
樓主提的這兩個測試:
https://www.facebook.com/groups/nas.tw/permalink/10154534902678245/
https://www.facebook.com/groups/nas.tw/permalink/10154536137713245/
一位是在 ds415+ 上做的,一位是在 ds1815+. 兩個各做一次,結果不同,一個是btrfs rebuild 快10%, 一個是 ext4 rebuild 快10%. 所以樓主的結論是
不同fs在不同的cpu上會有明顯差異. 而且應該要呈幾何成長.
我查了一下,這兩個2014年同期發佈的機種,ds415+ 和 ds1815+ 都是用同一顆 cpu intel c2538,我猜樓主是因為ds1815+槽多所以覺得它的cpu也是比較高階.才拿ds415+和ds1815+來比較, 不過看來是樓主誤解了,因為CPU 根本都是一樣的. 照這樣來看,還剛好証明rebuild 的速度和fs的關聯性不強.
我的認知和經驗也是如此, RAID rebuild 為了避免 reduild 佔了全部 io,在rebuild 期間系統會看狀況調節速度,所以每次rebuild的速度不會是一模一樣.
內文搜尋
從 APP 打開
X