我剛剛在大約 9 個月前安裝的兩台全新且相同的伺服器上發現了同樣的問題。我無法寫入它們的磁碟，因為系統已將其標記為唯讀。日誌顯示兩者都存在某種磁碟錯誤。
請注意，我在每台伺服器上運行帶有多個來賓的 KVM。來賓都運作良好，但問題出在 KVM 主機。這可能並不重要，但也許是相關的。兩個系統都只有兩個驅動器上面有軟體 raid1 和 LVM。每個 KVM 來賓也有自己的 LVM 分割區。
在查看時，兩個系統都顯示出降級的 RAID1 陣列/proc/mdstat。
所以我重新啟動了其中一個系統，它告訴我需要手動運行fsck.所以我就這麼做了。它似乎解決了問題，並且重新啟動使系統恢復正常。同樣的過程也適用於第二台伺服器。
接下來，我運行mdadm --manage /dev/md0 --add /dev/sdb1將發生故障的磁碟機新增回陣列中。這在兩台伺服器上都運作良好。在接下來的一個小時左右，請查看/proc/mdstat顯示驅動器同步方面的進展。大約一個小時後，一個系統完成了，並/proc/mdstat顯示一切運作良好[UU]。
然而，在另一個系統上，大約 1.5 小時後，系統負載激增，並且沒有任何反應。幾分鐘後，一切都恢復了。但現在來看，/proc/mdstat結果如下：
root@bond:/etc# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sda1[2] sdb1[1]
293033536 blocks [2/1] [_U]
unused devices: <none>
如您所見，它似乎不再同步。完成百分比、剩餘時間等不再顯示。然而，運行mdadm --detail /dev/md0顯示：
root@bond:/etc# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Mon Nov 30 20:04:44 2009
Raid Level : raid1
Array Size : 293033536 (279.46 GiB 300.07 GB)
Used Dev Size : 293033536 (279.46 GiB 300.07 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Fri Sep 10 23:38:33 2010
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
UUID : 4fb7b768:16c7d5b3:2e7b5ffd:55e4b71d
Events : 0.5104310
Number Major Minor RaidDevice State
2 8 1 0 spare rebuilding /dev/sda1
1 8 17 1 active sync /dev/sdb1
底線似乎表明備用件正在重建。為什麼是備用的？系統將兩台設備報告為乾淨。這樣已經持續了好幾個小時了。這些驅動器是小型且快速的 300GB 10K RPM VelociRaptors，所以我認為它現在應該已經同步了。嘗試重新新增表示設備正忙：
root@bond:/etc# mdadm /dev/md0 --re-add /dev/sda
mdadm: Cannot open /dev/sda: Device or resource busy
在「良好」伺服器上執行 dmesg 最後會顯示以下內容：
[ 4084.439822] md: md0: recovery done.
[ 4084.487756] RAID1 conf printout:
[ 4084.487759] --- wd:2 rd:2
[ 4084.487763] disk 0, wo:0, o:1, dev:sda1
[ 4084.487765] disk 1, wo:0, o:1, dev:sdb1
在「壞」伺服器上，最後 4 行會重複數百次。在「好」伺服器上，它們只顯示一次。
驅動器仍在同步嗎？這次「重建」能結束嗎？我只需要更有耐心嗎？如果沒有，我現在該怎麼辦？
更新：
我剛剛重新啟動，驅動器又開始同步。差不多2小時後，發生了與上述相同的事情（仍然得到[_U]）。然而，在 RAID1 conf 列印輸出區塊消耗掉所有日誌之前，我能夠看到 dmesg 日誌：
[ 6348.303685] sd 1:0:0:0: [sdb] Unhandled sense code
[ 6348.303688] sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 6348.303692] sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
[ 6348.303697] Descriptor sense data with sense descriptors (in hex):
[ 6348.303699] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 6348.303707] 22 ee a4 c7
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
所以也許我應該問的問題是“如何在 raid 集中的備用磁碟上運行 fsck？”
答案1
我不清楚您是否確實更換了故障磁碟機？因為如果您重新添加故障的驅動器，您的症狀對我來說是有意義的，在這種情況下，驅動器很可能已鎖定。如果您確實重新新增了故障驅動器，/var/log/messages 或 dmesg 中是否還會出現後續錯誤？
（順便說一句，我強烈建議不要將故障的驅動器重新添加到RAID 陣列。如果故障損壞了盤片上的數據，您可能會發現，當您將其添加回陣列時，重新同步會將損壞的文件保留在磁碟上光碟，下次讀取文件時，您會得到好數據還是壞數據，這取決於哪個磁碟首先響應；我已經在野外看到過這種情況。
答案2
使用 mdadm --details 將在重建時將磁碟機列為備用磁碟機。重建完成後，它將不再顯示為備用。
[ 6348.303711] sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[ 6348.303716] end_request: I/O error, dev sdb, sector 586065095
[ 6348.303753] ata2: EH complete
[ 6348.303776] raid1: sdb: unrecoverable I/O read error for block 586065024
[ 6348.305625] md: md0: recovery done.
第一行表示重新分配失敗，且未讀取資料。下面三行指出無法讀取數據，並列出了無法讀取的磁區。
正如羅傑指出的那樣，驅動器壞了，不要重新添加它。重新添加發生故障的驅動器絕不是一個好主意。拉出驅動器並更換它。如果您願意，可以對故障的驅動器運行診斷，但只能在將其拉出並更換後進行。
答案3
首先-是的，刪除任何引發讀取錯誤並最終出現在日誌檔案中的磁碟。這意味著壞塊重定位失敗和/或驅動器即將死亡。
我建議您使用 Linux 救援 CD 來救援您的數據，例如http://ubuntu-rescue-remix.org/使用 ddrescue。這可以將映像複製到新磁碟的分割區，並將進行大量重試等以嘗試還原分割區。掛載 USB 隨身碟或其他分割區
mkdir /tmp/x && 掛載 /dev/sdd1 /tmp/x
儲存 ddrescue 日誌檔案 - 然後您可以停止 ddrescue (ctrl-C) 並稍後從同一點重新啟動它。
在新磁碟上建立比舊磁碟稍大的分割區。您不必使用整個磁碟！
使用“nodmraid”作為核心引導參數來引導救援 CD。如果使用 ubuntu live CD，請安裝 RAID 和 LVM（如果您正在使用它）
apt-get 安裝 mdadm lvm2 gddrescue
您需要連接到互聯網才能進行此操作）。否則，請使用 ubuntu 救援 CD 執行 ddrescue 步驟。我在用於 ddrescue 運行的救援 CD 和用於 grub 和 fsck 工作的即時 CD 之間進行了交換。
假設 /dev/sdb 是發生故障的來源磁碟，/dev/sdx 是新磁碟，/mnt/x 是 USB 隨身碟或已安裝的另一個磁碟上的分割區。你需要ddrescue 日誌文件，真的！因為它追蹤 ddrescue 的進展情況，並允許其中斷。
按照http://www.forensicswiki.org/wiki/Ddrescue
ddrescue --no-split /dev/sdb /dev/sdX 映像檔 /mnt/x/logfile
然後
ddrescue --direct --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
然後
ddrescue --direct --retrim --max-retries=3 /dev/sdb /dev/sdX /mnt/x/logfile
如果恢復單一磁區需要幾個小時，請不要害怕按 Ctrl-C 執行該程序。只需繼續下一步（無論如何，步驟 1 都應該成功）。最後一步嘗試恢復最後的可用資料碎片。
你還必須做
mdadm --create /dev/md99 --level-1 --raid-devices=2 缺少 /dev/sdX
若要使用新磁碟建立新的 RAID 陣列，這會在分割區上寫入新的 RAID 超級區塊（在分割區末端的最後 64K 到 128K 中）。
從系統中刪除舊的故障磁碟 /dev/sdb，使其對 linux 不可見。
使您的來源 RAID 磁碟可存取。您可能必須對核心啟動核心使用「nodmraid」參數，因為我在使用 ubuntu 救援 CD 時遇到問題，最終使用了 Ubuntu live CD (10.4)，其中 nodmraid 位於 F6 選項中。你應該只需要使用
mdadm --assemble /dev/md99 /dev/sdX
然後進行 fsck 或對 md99 RAID 陣列上的資料執行所需的任何檢查（我使用 vgscan 然後能夠看到 LVM LV 來執行檢查）。我對 mytv 使用 XFS，但 xfs_check 命令使我的系統崩潰，但 xfs_repair 沒問題。
從新的 /dev/sdX 掛載 /boot 目錄
掛載 /dev/mapper/my_vg/root_lv /tmp/x
然後將新的 GRUB 開機記錄放在新的 /dev/sdX RAID 磁碟上（僅當您從 RAID 開機時！）
grub-setup -d /tmp/x/boot/grub /dev/sdX
現在您已經有了一個（幾乎）可啟動的 RAID 陣列。您也可以使用 GRUB 本身進行設置，或使用 dd 將 /dev/sdb 的前 446 位元組複製到 /dev/sdX。只有前 446 個字節，第一個磁區的其餘部分是你的分割表，如果你複製更多，你就會把它塞滿！您可能還需要對分割區 /dev/sdX1 中的第一個磁區執行相同的操作（例如）。也使用 dd 備份要覆蓋的所有磁區。
如果使用 grub2 並且從 RAID 啟動，您會發現 RAID 陣列 UUID 已更改，因此啟動將會失敗。編輯引導命令列（Grub 啟動面板中的 e）以刪除啟動和安靜，以便您可以看到發生了什麼。然後在啟動失敗後，您將留在 initramfs 中。
mdadm --assemble /dev/md99 /dev/sdX
然後檢查 /proc/mdstat 以確保該數組在那裡。如果是，那麼只需“退出”，希望您的GRUB 引導節能夠正常工作（我的引導節設定為使用LVM，因此一旦存在任何RAID 設備，它就會在RAID 設備上找到LV，它只會搜索LV）。一旦啟動，你就差不多完成了。
initrd 映像檔（gzip 壓縮的 cpio 檔案）包含引導過程中使用的 mdadm.conf 的副本，在引導過程中作為 /etc/mdadm/mdamdm.conf 可見且可編輯。如果您可以正常啟動系統，只需使用下列命令更新 initramfs
更新-initramfs -u
如果由於 mdadm.conf 檔案中的 UUID 不匹配而無法啟動系統
請注意，當您以不同方式啟動時（Grub、rescue、真實啟動），您的目標裝置 /dev/sdX 可能會顯示為 /dev/sdY。
順便說一句，除非您使用 RAID5 並且確實對區塊對齊感興趣，否則我會為您的 RAID 陣列使用一個分割區，您不必使用整個磁碟（特別是如果您用 2TB 磁碟替換 1TB 磁碟）一）。您可以隨時新增另一個分割區和第二個 RAID 陣列，以用完整個 2TB。
唷！完畢！