BTRFS 有雷 - 目前不適用於 RAID5/6

AKSN74 wrote:
目前我是RAID 10 + Btrfs的也建議轉回ext4嗎?

不需要, 但是如果下次更換到更大更多bay的 nas 時, 建議其它檔案格式.

pctine 兄, 其實你的測試可以不必做, 因為 btrfs 官網的 FAQ 其實寫的非常詳細



重點部分我特別框起來了. 今天 btrfs 或是任何的開源軟體團隊都會聲明以及註明我這個 package 應該怎麼應用, 應用的極限在哪裡. Synology 把這個非常有潛力的檔案格式變成了一個商品, 但是應該要告知的問題以及要小心的部分, 要注意應用的場景, 卻很失敗的沒有告知.

下面是一個 Qnap 工程師的說法, 可以提供參考
當checksum error發生在btrfs的RAID1,錯誤是可以被修正的。
當checksum error發生在btrfs on LVM + RAID1,錯誤是無法被修正的,除非你資料寫兩份。

所以Synology的方案是:metadata寫兩份,而且用checksum保護起來。

但是data的部份沒辦法寫兩份,雖然btrfs可以這樣設定,但是這樣空間使用率只有1/4。

也沒有辦法用lvm + RAID0 + btrfs 2-copies,因為btrfs沒辦法保證空間一定會分配在兩個不同的磁碟上。

講那麼多,結論就是Synology的btrfs方案沒辦法抵抗"silent data corruption"

他所說的情景也是 A+B= C, C 所產生的一個負面結果. LVM 很成熟, BTRFS 單獨一顆或是 RAID1 的時候也很穩定, 但是不代表 BTRFS 跟 LVM 在一起時, 都是非常麻吉, 成熟穩定的. 這部分就連 btrfs 官網的角度都有在做質疑的部分, 試問應該要解釋的一方, 是把產品推出來的 Synology 來解釋才對, 而不是在 Synology 2017 一張簡單的 ppt 幻燈片告知大家, 不用擔心 silent data corruption. BTRFS 可以防止 silent data corruption, 但是 BTRFS+LVM 這個答案就不一定了.
Oneplus 8 Pro• Thinkpad T480s• PVE6+OMV4+NextCloud
EluSiOn wrote:
不需要, 但是如果...(恕刪)


請教一下,
照QNAP工程師說法的話,以目前Synology的架構是btrfs on LVM,這樣的RAID1也是有風險的?

另外所謂的單thread的狀況是如何?如果是以存取連線數來看的話,這樣使用btrfs只剩下快照這個能力而已,再考慮到這種架構也存在風險的話,我覺得Synology真的不該推這樣的組合,等於喪失了NAS的容錯能力又無法提升讀寫效能.......
dummyhead wrote:
請教一下,照QNAP...(恕刪)
我需要更正一下. 是前任 Qnap 工程師, 目前已經不在 qnap 工作... 這個是我的疏忽.

dummyhead wrote:
照QNAP工程師說法的話,以目前Synology的架構是btrfs on LVM,這樣的RAID1也是有風險的?
是有風險的, 這部分也需要 Synology 出面回答.

dummyhead wrote:
另外所謂的單thread的狀況是如何?如果是以存取連線數來看的話,這樣使用btrfs只剩下快照這個能力而已,再考慮到這種架構也存在風險的話,我覺得Synology真的不該推這樣的組合,等於喪失了NAS的容錯能力又無法提升讀寫效能.......
單 thread 的原因是, BTRFS 只知道它有一個 block device, 就是 LVM, 所以當然只能單 thread 寫入, 無法啟用它內建的多工平行寫入多 device 的優化代碼. 說實話, 在 1 GBe 的網路環境, 4 x 3.5 HDD 的場景下, 最大頻寬就是 150 MB/s 而已, 所以 btrfs on LVM 這樣子的架構不會展現出來它的瓶頸問題.
.
但是下個世代的儲存設備開始都是 10 GBe, NVMe SSD 的環境下, 6 Bay & 8 Bay NAS 時, btrfs on LVM 就會凸顯出來. 這個也是 BTRFS 官網的 FAQ 不斷的強調這一點.
Oneplus 8 Pro• Thinkpad T480s• PVE6+OMV4+NextCloud

EluSiOn wrote:
單 thread 的原因是, BTRFS 只知道它有一個 block device, 就是 LVM, 所以當然只能單 thread 寫入, 無法啟用它內建的多工平行寫入多 device 的優化代碼.. ...(恕刪)


這論點是有問題的.

簡單說, 不管是任何 file system, 假設我們今天寫入一個 10GB 的檔案至 RAID, 這個 RAID 可能是 RAID0/1/5/6/..., 而 RAID 也可能是由不同顆硬碟所組成. 你所看到就是一個 10GB file 要寫入, 這相當於這裡所提的 single thread. 但進入 RAID 這個 black box 它要怎麼處理, 要用 multi-thread 同時去寫入多顆硬碟, 這難道不能做到嗎?

FB: Pctine

EluSiOn wrote:
BTRFS 可以防止 silent data corruption, 但是 BTRFS+LVM 這個答案就不一定了

喔喔, 所以現在問題又從效能跑到silent data corruption了...
那想請問一下, ext4 on LVM要如何解決silent data corruption的問題?
畢竟就我所知, ext4是連checksum都不做
而這又是目前各大nas廠的標準配備, 相信是更多人會關心的問題

betoptic wrote:
喔喔, 所以現在問題又從效能跑到silent data corruption了...
那想請問一下, ext4 on LVM要如何解決silent data corruption的問題?
畢竟就我所知, ext4是連checksum都不做
而這又是目前各大nas廠的標準配備, 相信是更多人會關心的問題...(恕刪)


其實這個討論串是非常正面的. 讓大家更了解 NAS 內部 file system 的運作.

除了 zfs & btrfs raid 有特別提到 slient data corruption外, 似乎在 ext4 上面也是做不到的.

現在小弟還真的非常期待 Synology DSM 6.1, 在發表會提到在該 NAS btrfs file system, 所有讀寫都能透過 checksum 來避免 silent data corruption.
FB: Pctine

EluSiOn wrote:
我需要更正一下. ...(恕刪)


謝謝回覆,我想再確認一下,因為您提供的來源網站內的確提到了RAID5/6的問題,可能我漏看了,是否有哪個地方或如何證實RAID 1也會有問題呢?還是如同pctine和betoptic所提的,這個問題其實目前所有的filesystem都會遇到?

如果都會遇到的話,就不見得是Synology應該要跳出來說明的,如果只有Synology這樣的設計導致問題,我覺得Synology才是需要出來說明的。

這個確實也踩到我的痛處,畢竟我想大多數NAS的使用情境是以資料完整性為優先(RAID 0以外),效能次之,不考慮來自外力損毀的前提下,如果單就Synology這樣的新架構會造成問題,我真的很難理解為什麼可以這樣推出。

而且我也打算在將來有機會會使用6-8 bay來作備援,如果這時備援效能會卡死在軟體架構,真的也說不過去......



pctine wrote:
其實這個討論串是非常...(恕刪)



想請教一下目前是否有相關的預計時程?
樓上
pctine wrote:
其實這個討論串是非...(恕刪)

不過做checksum的話 勢必又會影響到NAS的效能了
如果是像DS916+等這些效能比較好的機種影響可能不大

但對於中階或初階的ARM based NAS而言 傳輸檔案對它的負擔本身已不小
如果因此加個checksum的話 可能更會影響到傳輸效能?
樓主質疑的點很奇怪。除非樓主有證據說 LVM+btrfs 有像BTRFS 自己的 RAID 有難以解決的 bug,不然為何為何要轉移到其他檔案系統呢? 大家本來就清楚 因為多了快照跟壓縮功能,BTRFS 本來效能就比 ex4差啊。似乎也沒明確的數據說明在 LVM 上建立 btrfs 或是 ext4 raid Rebuild 時間差距(感覺應該不會差很多)。

廠商沒有用 btrfs 內建的 raid 就是因為它還不成熟,雖然效能一定比較好。然後改用傳統的RAID 上面掛檔案系統,還算是穩健的決策,目前看不出有什麼大問題。
文章分享
評分
評分
複製連結
請輸入您要前往的頁數(1 ~ 9)

今日熱門文章 網友點擊推薦!