個人積分：351分
文章編號：61925968
個人積分：1665分
文章編號：61926849
EluSiOn wrote:
測試結果已經完全出...(恕刪)
看了一下測試結果 寫入真的差滿多的
不過就測試方法這部分來看 是以RAID 1以及Basic來去判定
那麼再綜合前面的一些論述：
1. 以原生Btrfs架構去組RAID 5/6會有寫入問題 可能造成檔案損毀
2. S對於Btrfs目前都是採用LVM的做法
3. 經實測 以LVM的方式去部署Btrfs確實有寫入效能上的影響
4. 根據pc大的測試結果 EXT4與Btrfs都基於LVM的情況下 rebuild時間幾乎是沒有差距 (RAID 1)
這樣看下來 我的看法是以下這幾點
1. 原生Btrfs在RAID 5/6有問題 不過S因為都是採用LVM去架Btrfs而非原生 所以這個問題可以無視
2. 我知道dd的方式一樣是使用區塊的方式進行複製或搬移
但這是否等於RAID rebuild的情況 我覺得可能要再做驗證
畢竟不同的RAID架構 它在rebuild時所會採用的方式也不盡相同
反而我會比較想知道RAID 5/6/10的rebuild時間差異以及寫入速度差異
就目前的結果看起來 我還是對寫入速度是否會影響到rebuild這部分是存疑的
3. 如果是使用純硬碟而不是SSD的話 基本上不太需要去擔心寫入變慢的問題
(因為硬碟與網路因素 除非區網是使用10G或是以SSD在備份資料)
我寫這些本身是沒有要質疑樓主的測試結果 只是我認為這部分需要再探討一下
本身我也是認同樓主部分的看法
如果我有時間跟金錢的話 我也很樂意在DS916+做一次測試
個人積分：351分
文章編號：61936142
AKSN74 wrote:關於#4 pctine & gary 兩者的測試都是差距 10% 以上, 他們的測試跟 DD 不同喲, 這個 10% 在所有的 S x15+ 都會一樣的, 而且是不可以忽略的差異. 兩位測試者都是以 閒置狀態去 rebuild. 相同的 cpu 相同的 os 得到相同的差異 10%. 但是最詭吊的地方就是 一個人是固定 ext4 快, 一個人是固定 btrfs 快. 兩者的測試無法一致, 我也無法解釋是否有持續性的外在因素干擾了結果. 所以對這部分的測試我是感到很沮喪的.
那麼再綜合前面的一些論述：
...
...
4. 根據pc大的測試結果 EXT4與Btrfs都基於LVM的情況下 rebuild時間幾乎是沒有差距 (RAID 1)
一開始我以為 pctine 的測試是 415/415play 後來才注意到兩者的測試都是 x15+ 同款 cpu, 當我發現時, 也在第一時間與 pctine 在 line 群組討論這個問題. 基本上現在這個測試依然困擾着我, 但是我沒有相同的硬體以及多餘的時間可以測試... 令人感到非常的無奈.
AKSN74 wrote:1. 這部分其實一樓我原 po 就有說明
這樣看下來 我的看法是以下這幾點
1. 原生Btrfs在RAID 5/6有問題 不過S因為都是採用LVM去架Btrfs而非原生 所以這個問題可以無視
2. 我知道dd的方式一樣是使用區塊的方式進行複製或搬移
但這是否等於RAID rebuild的情況 我覺得可能要再做驗證
畢竟不同的RAID架構 它在rebuild時所會採用的方式也不盡相同
反而我會比較想知道RAID 5/6/10的rebuild時間差異以及寫入速度差異
就目前的結果看起來 我還是對寫入速度是否會影響到rebuild這部分是存疑的
3. 如果是使用純硬碟而不是SSD的話 基本上不太需要去擔心寫入變慢的問題
(因為硬碟與網路因素 除非區網是使用10G或是以SSD在備份資料)
2. RAID Rebuild 的測試我還在尋找更好的測試方式, 但是就目前 gary & pctine 的測試方式好像是最能量化的. 標準的 RAID Rebuild 都會跑 fsck 後再開始寫入資料, 不然 inode/journal 沒有修復前, 再繼續使用 pool 時, 資料損毀的機率實在太高了, 幾乎是 100%. 完整的 rebuild 的步奏參閱 https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID 到最後都是要跑我之前提到的 fsck.ext fsck.btrfs
我對於 RAID 模式的認定如下
- 1 寫入效能偏慢. (純 mirror, 不需要計算 parity) 但是 rebuild 速度是最快的, 完全只是純 resync
- 1+0 讀寫效能都是最快的, 特別是讀這部分, 但是容量損失 1/2 (純 mirror, 不需要計算 parity) 但是 rebuild 速度是最快的 , 完全只是純 resync
- 5 中規中矩 一個平庸的模式, 當 HD 越來越多時, 容錯比例較低.
- 6 寫入效能是最慢的, 其優點是拉高容錯比例. 其計算 parity 相對複雜. 一般所有任何網站公認說法都是 rebuild 時間最長的
3. 我一開始就說明了, 一般家用使用者目前影響不大, 但是高階硬體/企業用戶 應該要避開 btrfs on lvm 的架構. 任何企業最稀有的 IT 資源絕對是 IO 資源 (io 不是硬碟容量空間, 而是讀取寫入效能), 最充裕的則是 運算效能以及 RAM 效能. 所以大部分專業企業級的儲存系統, 都是盡量以 運算效能/ram 效能來換取 IO 資源. 但是 btrfs on lvm 的格式是以相反的邏輯, 以運算效能換取 一個 快照功能, 但是同時犧牲了 IO 效能.
Oneplus 8 Pro•
Thinkpad T480s•
PVE6+OMV4+NextCloud
個人積分：351分
文章編號：61936254
個人積分：351分
文章編號：61936298
個人積分：113分
文章編號：61937013
EluSiOn wrote:
2. RAID Rebuild 的測試我還在尋找更好的測試方式, 但是就目前 gary & pctine 的測試方式好像是最能量化的. 標準的 RAID Rebuild 都會跑 fsck 後再開始寫入資料, 不然 inode/journal 沒有修復前, 再繼續使用 pool 時, 資料損毀的機率實在太高了, 幾乎是 100%. 完整的 rebuild 的步奏參閱 https://raid.wiki.kernel.org/index.php/Recovering_a_failed_software_RAID 到最後都是要跑我之前提到的 fsck.ext fsck.btrfs
好像引用的連結不是樓主要證明的情況？
(1) 該連結的內容是在描述"資料救援"，並非"RAID rebuild"的一般過程。
大家在討論的"RAID rebuild" (以mdadm/LVM為例)，是指一般性的從現有的資料和Parity，計算出欠缺的資料，也就是修復陣列。
在你的連結中，"RAID rebuild只是它的情境設定，該流程的情境也可以設定為非reuild中的RAID，主要是"超過最大可允許損毀的硬碟數量時"這種情境 (RAID5壞了兩顆、RAID6壞了三顆....etc)，
(2) 該文中出現的fsck是在最後段，是為了確保檔案系統到最後還能掛載(後續才能去救援資料的部份)
那個並非是必要條件，而是讓結果會更好而已。它提到的第一步是先檢查，如果真的有出現檔案系統錯誤才需要修復。
同樣的，那也是因為它的情境設定 (損毀太多顆了導致檔案系統可能的問題)，正常的"RAID rebuild"根本不會走到這一段。
個人積分：0分
文章編號：61937414
EluSiOn wrote:
ZOL#3085 已經解決了啊 在 zfs 0.6.5 以及透過 setting swappiness to 0
SPL#388 也在 zfs 0.6.5 解決了, 特別是在這一版 kernel 4.4 LTS 裡面
請問能夠提供一下是哪一條 commit 解決這些問題的嗎？或者是 changelog 也行。截至 zfs-0.7.0-rc1 好像都還沒看到。spl-0.6.5 約進了 70 筆修正也都不是解這個問題，ticket 狀態也還是 open。
調整 swappiness 為 0 只是避開問題而已，談不上正解，而且還有其他操作觸發 shrink slab。
個人積分：0分
文章編號：61937567
pert916 wrote:
好像引用的連結不是樓主要證明的情況？
我也很好奇為什麼樓主在這個論點上，經常引用不相關的連結來佐證自己的立場。相同的疑問我也有再 #26 表示過，我的解讀是剛好搜尋的關鍵字出現在同一頁而已，但講的卻是不相干的事。
個人積分：1665分
文章編號：61946895
EluSiOn wrote:
2. RAID Rebuild 的測試我還在尋找更好的測試方式, 但是就目前 gary & pctine 的測試方式好像是最能量化的. 標準的 RAID Rebuild 都會跑 fsck 後再開始寫入資料, 不然 inode/journal 沒有修復前, 再繼續使用 pool 時, 資料損毀的機率實在太高了, 幾乎是 100%. 完整的 rebuild 的步奏參閱 ...(恕刪)
嗯...其實這部分有點奇怪
如果說RAID rebuild都會先跑fsck後再開始寫入資料
那在RAID rebuild的情況 應該會鎖死不給用吧?
可是不論是RAID 1/5/6/10 在有一顆或部分硬碟損壞時 NAS都還是可以存取資源的
並且在rebuild的過程中也可以
而且這樣的話 硬體RAID又會是怎麼做的呢?
有點好奇這部分
個人積分：745分
文章編號：61948232
AKSN74 wrote:
嗯...其實這部分...(恕刪)
因為樓主硬要套用 zfs 這種本身就有 RAID 功能的 filesystem 觀點到 mdraid 或硬體 RAID 來看.
問題是... 根本不能這樣子來看...
因為後兩者都不管 filesystem, 就算沒有格式化成任何 filesystem, 也一樣會有 rebuild/resync 的動作.
對 RAID 來說, 它只管相對應的每一個 block 是不是正確, 並不知道也不需要知道這些 block 上頭存放的是那一種 filesystem.
既然不知是什麼 filesystem, 自然就不會有需要 fsck 才能有 rebuild 這種動作了.
反過來看, filesystem 也不知道下一層的 device 是 RAID 還是硬碟或檔案.
因為 zfs 把 RAID 的功能做進去, 所以上面那些就可以混在一起看... 但, 問題是, 多數的 filesystem 是不管 RAID 的, 對它們來說, RAID, 硬碟, 或一個檔案都是一樣的.
