EluSiOn wrote:
兩位對 storage 架構真的了解不夠細膩. LVM 在 rebuild 的時候, 都需要call /sbin/fsck.btrfs
為何rebuild raid需要call fsck.btrfs?
換作在ext4上, 難道你把/sbin/fsck.ext4拿掉, raid就無法重建?
建議你先去實驗看看再來下結論
個人積分：30分
文章編號：61817708
個人積分：5084分
文章編號：61817769
個人積分：351分
文章編號：61818168
betoptic wrote:
為何rebuild raid...(恕刪)
所以就說技術文件讀一半很糟糕. mdraid 初建立時不管 file system. 但是修復時一定會跟 file system 一起配合操作的. 所有修復 raid 執行前, 都會先要求跑一次 file consistency check, 確認沒有問題後, 再執行 raid rebuild, 因為 FC check 一直都是 rebuild 的一個 sub-routine. 有的時候也會使用 resync 這個 sub-routine.
raid volume rebuild 成功, 但是 file system corrupt 無法讀取叫做成功修復嗎? fsck 以及 resync 的情況時, 都一定會叫 file system 下面的 process/api 的.
Oneplus 8 Pro•
Thinkpad T480s•
PVE6+OMV4+NextCloud
個人積分：30分
文章編號：61818298
個人積分：351分
文章編號：61819048
個人積分：0分
文章編號：61819126
EluSiOn wrote:
官網的說的很明白, 使用 BTRFS on LVM Synology 這種架構, 會有寫入效能的損失. 官方的開發者說的很明白, 清楚, 這樣子的架構會讓 BTRFS 寫入的優化完全失效. ineffective 是一個超級負面的字 (not producing any significant or desired effect)
號稱 the future of Linux filesystems 的 Btrfs 野心很大，想要在 filesystem 這層一口氣吃下 Raid/LVM 要做的事，少了疊床架屋，想也知道要比較快，所以他們當然會說配 LVM ineffective (有很負面嗎？)。
不過實際上就是 Btrfs RAID 很不爭氣的，要嘛不能用，不然就是效能測出來跟配 RAID/LVM 不相上下，看來離這些開發者的夢想還有一段距離。
目前有支援 Btrfs 的 NAS 廠，在 Btrfs RAID 不堪用的狀況下，幾乎都是把 Btrfs 打回和 Ext4/XFS 一樣搭配 LVM + RAID 的架構。很好奇樓主是否有更好的建議。
EluSiOn wrote:
現在很多企業級儲存系統, 根本不使用 lvm. Oracle 甚至說
we recommend that Logical Volume Manager (LVM) not to be used for the boot disk.
這句話只是很單純說 boot device 不需要搞 LVM 弄得太麻煩而已，好像跟你的論點無關。
另外 LVM 其實很常被使用，在 Redhat 的維護下也一直很穩定，要戰 Btrfs 應該也不用把 LVM 拖下水啊。
EluSiOn wrote:
The filesystem is not relevant before creating the array. mdadm does not "clobber" both drives, it just copies the contents of the primary to the secondary when mirroring. If the primary already had an ext4 filesystem in it, then it will still look like it does, and after the resync , so will the second. The new default mdadm metadata format of 1.2 is stored 4k from the start, so it will have overwritten and damaged the filesystem that was there before.
如果只讀到前面一半, 後面一半沒有讀! 那很恐怖的!
這一段出處應該是來至 AskUbuntu 吧，原本的提問者要問的是建 RAID 前可不可以先建 ext4。mdadm 1.2 把 metadata 放在前頭，如果原本硬碟上有 ext4，就會被覆蓋掉 (so it will have overwritten and damaged the filesystem)。這篇引述的文章跟你的論點好像也沒關係，也沒有要 fsck 的操作，RAID rebuild 會牽扯到上層的 filesystem 的確是比較特別的說法，可能要請樓主提供其他參考資料作為佐證這是必要的行為了。
個人積分：30分
文章編號：61819248
個人積分：351分
文章編號：61820785
AristotleC wrote:
不過實際上就是 Btrfs RAID 很不爭氣的，要嘛不能用，不然就是效能測出來跟配 RAID/LVM 不相上下，看來離這些開發者的夢想還有一段距離。
你的說法跟 phoronix.com 不同喲. 當 mdraid 在 2顆 hdd 以及 單 thread 這樣子的情景下, 效能是比 btrfs raid 強的.
但是如果是 4顆以上 多 thread 的情景下, btrfs raid 效能就開始強過 mdraid. 不管是 raid1+0 或是 4顆raid1.
http://www.phoronix.com/scan.php?page=article&item=linux47-btrfs-mdadm#=1
AristotleC wrote:
另外 LVM 其實很常被使用，在 Redhat 的維護下也一直很穩定，要戰 Btrfs 應該也不用把 LVM 拖下水啊。
重點在於 lvm (A) + btrfs (B) 的結合產生的結果 "C", A + B = C... 現在的問題是 C 這個結果有寫入效能慢. 關 A 或是 B 什麼事情? 這個是基本邏輯吧.
Oneplus 8 Pro•
Thinkpad T480s•
PVE6+OMV4+NextCloud
個人積分：1665分
文章編號：61821121
EluSiOn wrote:
你的說法跟 phoronix...(恕刪)
目前我是RAID 10 + Btrfs的也建議轉回ext4嗎?
我是覺得目前這樣看下來 只能說應該是各有優缺吧?
每一個選擇都一定會有得失
總之目前看下來有一些結論
1. Btrfs RAID會有遺失資料的風險 但目前沒有直接採用這種RAID 因此可以無視
2. 目前Synology用的LVM + Btrfs會有寫入效率慢的問題 → 衍生RAID5/6在重建時可能會花比較久的時間
比較久的時間=增加硬碟出錯的風險
3. 建議如果是企業用戶轉移回ext4
不過目前看下來對我而言...
1. RAID 10的重建時間跟影響規模應該不會像RAID 5/6這麼大
(因為當RAID 10 中個其中一顆損壞時 跟做1的那顆硬碟做rebuild就可以了)
2. 寫入速度還是限制在網路 所以這樣的建置對寫入效能有影響 但受網路限制影響多少可以無視
除非NAS用10G
3. 其實我個人也滿好奇rebuild時是否一定得去存取檔案系統
因為印象中RAID在做rebuild的時候是以block的方式做複製搬移的
個人積分：5084分
文章編號：61821219
