搜索
Table_bottom

标签云
Table_bottom

分类
Table_bottom

声明
文章若未特別註明,皆採用 知识共享许可协议 請自覺遵守
Table_bottom

鏈。。。
Table_bottom

存档
Table_bottom

匆匆过客
83659
Table_bottom

功能
Table_bottom

記日前硬盤故障

先描述一下我的計算機概況:

500G硬盤,前大約100G是OEM的Windows7及其預置恢復分區(sda1-sda3),後邊全給了linux用。除了/boot,文件系統格式全是ext4,/home(sda6)有200G+。

發行版是arch,引導器是grub2。


某日,需要進Windows做點事,於是重啓電腦。到了引導項選擇那裏,由於我設置的是隱藏菜單(默認進arch),故而需要按ESC使菜單顯示出來。然而,我手快了些,在5s的倒計時開始前就按了ESC。然後只見硬盤持續亮着,引導菜單沒有出現。等了一會,實在不耐煩,於是長按電源,再開。這次刻意等到讀秒開始之後再按的ESC,引導項選擇也出現了,選擇Windows,確認。Windows的啓動用了很長時間,輸入密碼之後那個“歡迎”也持續旋轉很久。我以爲是上次安裝了一些更新所致,也沒有在意,之後使用沒什麼奇怪現象。

等到處理完,重啓進Arch時候,看到問題了:一直在報sda6一些塊讀取錯誤。看到這裏,大概判斷是硬盤有了壞塊,於是長按電源鍵,關掉了計算機。再次啓動時候是用U盤引導(上次給人裝Arch時候直接把鏡像dd到U盤),繼續看到sda6某某塊讀取出錯,不過這次倒是進了live系統。

然後用badblocks檢測,發現還真是有,主要分佈在sda6上,sda7也有少量。這下就令人着急了——數據可是無價的。幸好手上有個1T且只裝了一半的移動硬盤,可以將數據轉入。

然而,嘗試只讀掛載sda6的時候,提示superblock讀取失敗,拒絕掛載。上網一查,發現ext4會創建備份的superblock,於是按照網上說的,掛載時加上-o sb=xxx參數指定副superblock的塊號。這裏我man了一下mount,發現這個參數是以1K爲標準的。我創建的文件系統塊大小是4K,所以第32768塊的備份superblock應該用-o sb=131072參數。

這樣,連起來的掛載命令就是

mount -r -o sb=131072 -t ext4 /dev/sda6 /mnt/sda6

滿懷期待得讓命令執行,卻再次得到信息說“掛載失敗,可能是錯誤的文件系統類型”。看到這點時候真的有些慌,因爲我確認它是ext4,而掛載時候卻告訴我失敗,莫非數據真的無法挽救?之後又嘗試用其他的副superblock,結果卻沒有什麼變化。

這時候我抱着試試看的心態敲了一下dmesg,在最下邊看到journal讀取失敗,於是拒絕掛載。心情一下清平了,再掛載時候加上norecovery參數,掛載成功,備份數據。

最終的命令如下:

mount -r -o sb=131072,norecovery -t ext4 /dev/sda6 /mnt/sda6

慘痛的經歷再次說明經常備份數據的重要性。

以及,若有遇到類似情況的,望可告知產生原因是什麼……

(某想不通究竟是因爲斷電導致的還是確實是grub的bug……更不想再試試……)