“zpool replace”掛起並鎖定池
鑑於我的四個磁碟 RAIDZ1,一個磁碟在物理上變得嘈雜,尚未產生錯誤,但聽起來也不健康。所以我選擇先發製人地替換它。
我已經做好了:
zpool offline tank0 ad6
關閉、移除和更換磁碟
zpool replace tank0 ad6 ad6
永遠掛著。
zpool status
也永遠掛起,zpool history
.如果我在移除磁碟的情況下重新啟動機器,一切正常,如預期的那樣處於降級模式。
現在我該怎麼做?擔心,因為我的數據現在容易受到單個磁碟故障的影響。
作業系統是 FreeBSD 7.3-RELEASE-p1 - 又名 FreeNAS 7.0.2.5226
我剛剛在 VM 中嘗試了相同的操作,儘管 FreeBSD 7.3-RELEASE-p7(FreeNAS 0.7.2.8191,稍晚版本) - 完美執行。嘗試使用我現在能找到的最舊版本的 FreeNAS(7.0.2.5799),稍後會更新。
另外,
zpool replace
不需要使用文件系統嗎?NAS 上的另一個守護程序可能正在使用該文件系統。我認為這沒問題,但這當然可能是錯誤的。更新,2012-01-10
我用 FreeNAS 8 啟動了機器並做了
zpool replace
- 它開始了,並立即開始拋出大量數據損壞錯誤和核心恐慌 - 儘管每周清理池從未發現任何問題。我認為我沒有做任何愚蠢的事情,比如告訴它更換錯誤的磁碟。我立即發出shutdown -h
,因為我知道數據很好。無論如何,我現在有一個降級的池,卡在替換暫停的狀態,我正在將我的數據複製到一個 3TB 的外部驅動器,花了很多錢購買,所以我可以銷毀池並重新開始。值得慶幸的是,數據看起來還不錯——我碰巧有大約 100GB 的文件的 md5sums,到目前為止似乎完好無損,而且我已經設法恢復了所有真正不可替代的東西。
我現在正在等待更多 RAM 的到來,因為 FreeNAS 8 一直因 kmem_max 太小的錯誤而恐慌,我似乎無法調整,而且機器受到 RAM 限制(1 GB RAM 用於 4TB RAIDZ1)。
關於備份的慘痛教訓,但也確實打擊了對 ZFS/FreeNAS/FreeBSD 的信心。
2012 年 13 月 1 日更新
好吧,我的數據現在似乎已安全備份。
即使將故障模式設置為繼續,zpool status -v 也會掛起。這是 zpool status 的輸出,插入了新磁碟 (ada1)
pool: tank0 state: DEGRADED status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: none requested config: NAME STATE READ WRITE CKSUM tank0 DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 ada0 ONLINE 0 0 0 replacing DEGRADED 0 0 3.17K 6540253751212815210 UNAVAIL 0 0 0 was /dev/ada3/old ada1 ONLINE 0 0 0 errors: 3130 data errors, use '-v' for a list
插入舊磁碟而不是新磁碟,ZFS 不會導入池,並
zfs status
說:tank0 UNAVAIL insufficient replicas raidz1 FAULTED corrupted data ada2 ONLINE ada3 ONLINE ada0 FAULTED corrupted data replacing UNAVAIL insufficient replicas ada1 FAULTED corrupted data ada1 FAULTED corrupted data
我不明白為什麼 ada0 應該在插入新磁碟 (ada1) 的情況下出現故障,但在插入舊磁碟的情況下會聯機?我看不出 ada0 是如何相關的。
讓我們嘗試恢復這個池作為學習練習。
真的被這個逼到了牆角。最終使池變平並將文件從備份恢復到 FreeNAS 8。
到目前為止感覺更穩定 - 較新的 x64 作業系統,4GB RAM 可能都有貢獻。
我不是 ZFS 專家,但我會試一試:聽起來 ZFS 子系統仍在嘗試訪問故障驅動器,並且由於某種原因掛起。嘗試將池的
failmode
值設置為continue
(zpool set failmode=continue
),看看這是否會使掛起消失並讓您弄清楚發生了什麼。(請注意,這不是修復:系統仍然無法訪問它認為應該能夠訪問的驅動器,它只是告訴它返回錯誤並繼續執行,而不是阻塞直到收到答案。)