Linux

Linux (FC14/i386) 在熱 fs 安裝後 raid1 是否完好?如何修復?

  • June 9, 2011

我的舊 (FC11) 安裝已達到 EOL,我嘗試在其 RAID1 根文件系統上重新安裝 FC14。

我現在懷疑,在安裝 FS 之後沒有完全突襲。問題是這種懷疑是否屬實,如果是,如何解決。

[root@atlas dev]# cat /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sda[0]
 732571648 blocks super external:/md0/0 [2/1] [U_]

md0 : inactive sdb[1](S) sda[0](S)
 4514 blocks super external:imsm

unused devices: <none>
[root@atlas dev]#

md127 似乎是 md0 的某個子容器,但列出了 sda

[Math Processing Error]$$ 0 $$作為顯式設備,但不是 sdb。我假設我正在使用 sda 閱讀這篇文章,而 sdb 已經失效。 問題是 FS 已經看到了相當多的動作,所以不能假設兩張光碟是同步的。sdb 可能必須重建。不過,我確實有完整的備份,所以我願意承擔經過計算的風險。

請注意,文件系統是根設備。(單使用者模式?)

也歡迎任何解釋如何閱讀 mdstat 輸出。我的猜測是我需要以某種方式將 sdb 從 md0 容器添加到 md127。

核心摘錄:

         dracut: Starting plymouth daemon
         dracut: rd_NO_DM: removing DM RAID activation
         pata_marvell 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
         pata_marvell 0000:03:00.0: setting latency timer to 64
         scsi6 : pata_marvell
         scsi7 : pata_marvell
         ata7: PATA max UDMA/100 cmd 0xcc00 ctl 0xc880 bmdma 0xc400 irq 16
         ata8: PATA max UDMA/133 cmd 0xc800 ctl 0xc480 bmdma 0xc408 irq 16
         dracut: Autoassembling MD Raid
         md: md0 stopped.
         md: bind<sda>
         md: bind<sdb>
         dracut: mdadm: Container /dev/md0 has been assembled with 2 drives
         md: md127 stopped.
         md: bind<sda>
         md: raid1 personality registered for level 1
         md/raid1:md127: active with 1 out of 2 mirrors
         md127: detected capacity change from 0 to 750153367552
          md127: p1 p2
         md: md127 switched to read-write mode.

–detail –scan 的輸出:

ARRAY /dev/md0 metadata=imsm UUID=e14582dd:1863c14a:fb0d98f0:5490080b
ARRAY /dev/md127 container=/dev/md0 member=0 UUID=c0cf0b37:bc944eec:ac93d30e:ee2f423e

/etc/mdadm.conf:

# mdadm.conf written out by anaconda
MAILADDR root
AUTO +imsm +1.x -all
ARRAY /dev/md0 UUID=e14582dd:1863c14a:fb0d98f0:5490080b
ARRAY /dev/md127 UUID=c0cf0b37:bc944eec:ac93d30e:ee2f423e

更新:

在等待一天的大部分時間之後,我咬緊牙關,驗證了我的備份,啟動到單使用者模式,然後我可以簡單地 mdadm –manage /dev/md127 –add /dev/sdb

重建大約需要 3 個小時(無償加班)。一切似乎都正常工作並且看起來完好無損。

我還記得在決定使用軟體 RAID 之前,我已經乾預了 fakeraid,儘管在其他磁碟上 afaik。也許 md0 是遺留下來的,它被一個恢復不佳的 /etc 滑入,然後一直打到它起作用。下一次重新安裝它在我的臉上炸毀了。讓它工作的實驗可能為它保留了一些資訊。

可怕的是現在兩個陣列都包含相同的磁碟,並且 md0 在啟動期間短暫啟用。我收到的警告似乎表明 md127 是 md0 的子級,這使得刪除有點可怕。但是我會挖一個引導盤,然後在第二天我有時間進行系統管理時試一試。(當然是在對昨天的完整備份進行增量備份之後)

md127 有兩個分區(一個大根 + 交換),都已安裝。md0 沒有啟動(我不敢啟動它,因為它共享驅動器),所以我不知道它有哪些分區。

由於 md127 現在可以工作(2/2 UU),現在需要確定是否可以安全刪除 md0(md0 的 md127 子級?),如果可以,如何避免在未來安裝時出現問題。

可能還需要殺死磁碟上的一些元數據,以避免下一次安裝拾取它。

正確的做法是首先弄清楚掛載了哪個分區。然後,您需要停用另一個,以便從中取出磁碟。然後在 mdadm 下增長掛載的磁碟以添加新磁碟,md 軟體會將目前掛載的分區同步到另一個磁碟。之後 cat’ing /proc/mdstat 應該只顯示一個 md 設備,其中列出了兩個磁碟(並且可能一個仍在同步)。(並可能修復 fstab)

我不會在這裡重複很多需要的內容,因為linux raid wiki非常好,並且包含您需要閱讀的大部分文件(以及很好的範例)。

然而,大多數人忘記的一件事是 linux 核心需要一個包含所需磁碟資訊的 initramfs。因此,每當您更改 md 配置時,明智的做法是使用 dracut 重新創建 initramfs:

dracut -v --mdadmconf new_image.img KERNEL-VERSION-STRING

然後將 grub 指向 new_image.img。

在從陣列中刪除驅動器並最終啟動單個驅動器而不是正確鏡像的驅動器之後,我犯了一個錯誤,即忘記了這一點。與您似乎所處的情況非常相似。

引用自:https://serverfault.com/questions/264253