我在 Debian wheezy 安裝上的主分割區是一個加密的 LVM 磁碟區。是ext3。今天早些時候，我在終端機視窗中收到一條奇怪的訊息，稱嘗試寫入/home樹中的檔案由於只讀檔案系統而失敗。我重新啟動並最終收到一條錯誤訊息/dev/sda1 is reported as clean. fsck.ext3，該訊息自動運行並報告沒有這樣的設備，/dev/mapper/sda1_crypt並報告退出代碼 8 /var/log/fsck/checkfs。
該日誌寫道：
[Timestamp]
fsck from util-linux 2.20.1
/dev/mapper/sda1_crypt: Super blocks need_recovery flag is clear, but journal has data.
/dev/mapper/sda1_crypt: Run journal anyway
/dev/mapper/sda1_crypt: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
(i.e., without -a or -p options)
fsck died with exit status 4
我跑了
$ fsck -vnM /dev/mapper/sda1
一堆illegal block #nnnn (mmmmmmmmm) in inode ppppppp IGNORED消息呼嘯而過，緊接著
too many blocks in Inode somenumberhere
然後運行額外的傳遞來解析多個 inode 宣告的區塊
然後輸出
Pass 1B: Rescanning for multiply claimed blocks
過了一會兒，我得到了一堵牆
Illegal block number passed to ext2fs_test_block_bitmap somenumberhere for multiply claimed block map
接下來是 I 節點 anothernumber 中的 2 個乘法宣告區塊：[5 和 8 區塊編號的清單]
然後我得到了一些像這樣的節
[ 3828.181915] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 3828.182462] ata1.01 BMDMA stat 0x64
[ 3828.183810] ata1.01 failed command: READ DMA EXT
[ 3828.185889] ata1.01 cmd 25/00:08:08:10:9c/00:00:29:00:00/f0 tag dma 4096 in
[ 3828.185891] res 51/40:00:09:10:9c/40:00:29:00:00/f0 Emask 0x9 (media error)
[ 3828.190071] ata1.01 status: { DRDY ERR }
[ 3828.192153] ata1.01 status: { UNC }
隨後是
[ 3830.509338] end_request: I/O error, deb SDA, sector 698093577
[ 3830.509841] Buffer I/O error on device dm-3, logical block 87261184
Error reading block 87261184 (Attempt to read block from filesystem resulted in short read) while reading I node and block bitmaps. Ignore error? no
fsck.ext3: Can't read an block bitmap while retrying to read bitmaps for /dev/mappersfa1_crypt
/dev/mapper/sda1_crypt: ******* WARNING: Filesystem still has errors *******
e2fsck: aborted
/dev/mapper/sda1_crypt: ******* WARNING: Filesystem still has errors *******
它中止並警告檔案系統仍然有錯誤。
我的問題是：
我的資料被烘烤了嗎？ （我嚴格的備份政策最近沒有嚴格遵守；我確信我正在受到宇宙的懲罰。）
我現在可以/應該做什麼？
難道我已經做錯事了嗎？
有人會抱住我到震動停止嗎？
編輯
我還在本地 LUG 郵件列表上詢問過。我得到的建議是使用 ddrescue 拍攝磁碟機的映像，並在該映像的副本上執行 fsck。這似乎很合理，而且不太可能讓事情變得更糟。所以，這就是目前的攻擊計劃，等待任何更好的建議。
答案1
感覺是硬碟本身有問題。 （“短讀”等）如果是這樣，dmesg | tail可能會顯示一些 I/O 錯誤。
檢查這一點的另一種方法是badblocks -n在有問題的分區上運行。或者更好，在整個磁碟上。無論您測試什麼，都需要將其卸載。在大型現代磁碟上這將需要幾個小時。如果分割區上確實安裝了您無法離開的任何內容，請先將其複製到可移動媒體或網路磁碟區上。
對磁碟進行鏡像的建議也很好。這是一種「精簡」版本的badblocks -n檢查，因為透過強制磁碟讀取每個磁區，它可能會導致磁碟重新定位問題區塊，正如badblocks -n所願。badblocks -n更有效，因為有問題的磁區幾乎無法讀取，並且只能透過嘗試寫入這些磁區來將其顯示為壞到足以移動的程度。不過，如果磁碟還有足夠的壽命能夠在救援中倖存下來，那麼額外的讀取通道將不足以完成它。
fsck我對在磁碟映像上運行能夠恢復一切不抱太大希望。在此過程中您幾乎肯定會丟失扇區，這意味著某些檔案將無法讀取或損壞而無法使用。例如，JPEG 將使用損壞的資料進行部分解碼，但底部 ⅔ 被裁剪掉的 JPEG 可能對您沒有用處。
我的資料被烘烤了嗎？
可能，也可能不是。通行證badblocks -n有時可以解決問題。如果是這樣，您仍然需要更換 HDD，因為磁碟只有在幾乎無法啟動時才會進入這種糟糕的狀態。
難道我已經做錯事了嗎？
除了忘記“嚴格”這個詞的含義之外，沒有。 :)
答案2
希望您有可以從中復原的目前備份映像。
我現在會對您想要保留的任何內容進行有限備份，然後檢查磁碟是否仍然可用。我曾經使用的一個技巧是使用 RAW 分區設備並將其添加到 /dev/null ......透過適當的選項，將識別無法讀取的區域。