引用:
|
作者海豹
原來我遇到的事不是個案喔... 
另外...nas不是一開始raid類型選好,然後偶而看看有沒有錯誤訊息的東西嗎?
如果日誌看不出來有什麼異常,還可以做什麼動作來提前預防  |
預防就是多做 checksum
在群輝裡面好像就是檢查完整性之類的功能
有分成完整跟快速兩種，可以把這檢查作成例行性排程
每個月建議至少做一次
如果發生 silent data corruption 的話
你在 log 當然不會看到任何訊息
看得到的話就不會稱作 "silent" data corruption
因為硬碟上資料也是有冷門跟熱門的區別
冷門資料如果長時間不存取
一旦損毀產生，你 RAID 群組中又有硬碟發生故障
然後損毀的資料又剛好不是在這顆故障硬碟上
你又只做 RAID5 ，系統也不知道發生 silent data corruption
rebuild 到那壞區的時候才發現 build 不起來
當然會整個崩潰
第二種情況:
如果你使用 RAID5，silent data corruption 先前已經發生過
如果你在更多 silent data corruption 發生之前有做過 checksum
系統就可以發現壞區，並嘗試修復
這時候有非常高的機率是可以完全修復
第三種情況:
如果使用 BTRFS, ZFS 之類支援 copy on write 功能
並使用 RAIDZ1 or RAID1含以上具容錯的模式
在狀況二中，用戶就算從不跑 checksum
某天你存取到這壞區的時候
檔案系統自己就會發現 crc error
然後就自己重寫一份，在別的區塊
自己就修復了，使用者只有在檢查 status 的時候才會發現曾經修復了多少大小的檔案
事實上 FreeBSD 跟 OpenZFS 官方都不建議執行跑全區 checksum
只要你的 RAID 等級足夠，所有的壞區只要經過存取都會自動修復
這也是不建議使用 RAID-5/RAIDZ1 的原因之一
引用:
|
作者twu2
看起來應該是在 DSM 7.0 才有? 這時該高興機器太舊, 不在自動升級的列表上嗎....
用 btrfs 應該只是要它的 snapshot, 所以這點夠強就會讓這些廠商選擇使用.
應該沒人用 btrfs 本身的 RAID 功能. 大家還是用 mdadm 在處理.
另外就是這些廠商的 kernel 都很舊, 相對來說, btrfs 很早就進到 linux kernel 中, 不用改太多. 但 openzfs 可能就要改不少東西.
一般就是定時做 RAID 的 scrubbing, 如果是用 btrfs, 也要定時做 btrfs 的 scrubbing.
|
BTRFS 本身的 RAID 跟 LVM 不衝突阿
你要一起用也沒問題
而且 BTRFS 有世界最強 RAID 切換彈性
只要容量沒有超出需求
可以在任意 RAID 模式之間轉換
不損失任何資料
BTRFS 強項不只快照，copy on write 這也是殺手級功能
對資料的安全有非常大的作用
實際上 OpenZFS 大部分時間都沒有進過 Linux kernel
為了規避 GPLV2 授權衝突問題，大部分 Linux 發行版的作法是掛 DKMS
kernel 完全不需修改
如果要直接進 kernel 就把 OpenZFS code 合併進 kernel 就好
不需要改甚麼東西，頂多就編譯參數開啟相關功能
群輝就算 kernel 鎖定特定版本，只做安全相關更新
一樣合併 BTRFS code 進他們自己維護的 kernel
就完成更新了