題 mdadm:Win7-install在我的一個RAID6驅動器上創建了一個啟動分區。如何重建?


當我試圖在自己的SSD上安裝Windows 7時,我的問題就出現了。我使用的具有軟件RAID系統知識的Linux操作系統位於我在安裝之前斷開連接的SSD上。這是因為窗戶(或我)不會無意中弄亂它。

然而,回想起來,愚蠢的是,我把RAID磁盤連接起來,認為windows不會那麼荒謬,以至於它看起來只是未分配的空間。

男孩,我錯了!將安裝文件複製到SSD後(如預期和所需),它還創建了一個 ntfs 其中一個RAID磁盤上的分區。既意外又完全不受歡迎! screenshot of ntfs partition on raid disk     。

我改變了 SSD再次,並在Linux中啟動。 mdadm 似乎沒有像以前那樣組裝數組有任何問題,但如果我嘗試安裝數組,我收到錯誤消息:

mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

dmesg

EXT4-fs (md0): ext4_check_descriptors: Block bitmap for group 0 not in group (block 1318081259)!
EXT4-fs (md0): group descriptors corrupted!

然後我用了 qparted 刪除新創建的 ntfs 分區 /dev/sdd 這樣它就匹配了其他三個 /dev/sd{b,c,e},並請求重新同步我的陣列 echo repair > /sys/block/md0/md/sync_action

這花了大約4個小時,完成後, dmesg 報告:

md: md0: requested-resync done.

雖然我不確定其他日誌文件存在的位置(我似乎也搞砸了我的sendmail配置),但在4小時的任務後有點簡短。在任何情況下:根據不報告變化 mdadm一切都檢查出來。 mdadm -D /dev/md0 仍然報導:

        Version : 1.2
  Creation Time : Wed May 23 22:18:45 2012
     Raid Level : raid6
     Array Size : 3907026848 (3726.03 GiB 4000.80 GB)
  Used Dev Size : 1953513424 (1863.02 GiB 2000.40 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Mon May 26 12:41:58 2014
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 4K

           Name : okamilinkun:0
           UUID : 0c97ebf3:098864d8:126f44e3:e4337102
         Events : 423

    Number   Major   Minor   RaidDevice State
       0       8       16        0      active sync   /dev/sdb
       1       8       32        1      active sync   /dev/sdc
       2       8       48        2      active sync   /dev/sdd
       3       8       64        3      active sync   /dev/sde

嘗試安裝它仍然報告:

mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

dmesg

EXT4-fs (md0): ext4_check_descriptors: Block bitmap for group 0 not in group (block 1318081259)!
EXT4-fs (md0): group descriptors corrupted!

我有點不確定從哪裡開始,嘗試“看看它是否有效”的東西對我來說有點冒險。這是我建議我應該嘗試做的事情:

告訴 mdadm 那 /dev/sdd (Windows寫入的那個)不再可靠,假裝它重新引入陣列,並根據其他三個驅動器重建其內容。

在我的假設中,我也可能是完全錯誤的 ntfs 分區 /dev/sdd 隨後的刪除改變了一些無法通過這種方式修復的東西。


我的問題:  幫助,我該怎麼辦?如果我應該按照我的建議去做,我該怎麼做?從閱讀文檔等,我想也許:

mdadm --manage /dev/md0 --set-faulty /dev/sdd
mdadm --manage /dev/md0 --remove /dev/sdd
mdadm --manage /dev/md0 --re-add /dev/sdd

但是,文檔示例提示 /dev/sdd1,這對我來說很奇怪,因為就linux而言,沒有分區,只是未分配的空間。也許沒有這些命令就行不通。

也許在之前鏡像其他一個未被觸摸的raid設備的分區表是有意義的 --re-add。就像是:

sfdisk -d /dev/sdb | sfdisk /dev/sdd

獎金問題:  為什麼Windows 7安裝會做出如此嚴重的事情......有潛在危險?


更新

我繼續前進並標記 /dev/sdd 因為有問題,並從陣列中刪除它(非物理):

# mdadm --manage /dev/md0 --set-faulty /dev/sdd
# mdadm --manage /dev/md0 --remove /dev/sdd

但是,嘗試-re-add是不允許的:

# mdadm --manage /dev/md0 --re-add /dev/sdd
mdadm: --re-add for /dev/sdd to /dev/md0 is not possible

--add,很好。

# mdadm --manage /dev/md0 --add /dev/sdd

mdadm -D /dev/md0 現在報告州 clean, degraded, recovering,和 /dev/sdd 如 spare rebuilding

/proc/mdstat顯示恢復進度:

md0 : active raid6 sdd[4] sdc[1] sde[3] sdb[0]
      3907026848 blocks super 1.2 level 6, 4k chunk, algorithm 2 [4/3] [UU_U]
      [>....................]  recovery =  2.1% (42887780/1953513424) finish=348.7min speed=91297K/sec

nmon 還顯示了預期的輸出:

│sdb        0%   87.3    0.0|  >                                              |│
│sdc       71%  109.1    0.0|RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR           > |│
│sdd       40%    0.0   87.3|WWWWWWWWWWWWWWWWWWWW           >                 |│
│sde        0%   87.3    0.0|>                                                ||

到目前為止看起來不錯。再過我的手指五個小時:)


更新2

恢復 /dev/sdd 完了,有 dmesg 輸出:

[44972.599552] md: md0: recovery done.
[44972.682811] RAID conf printout:
[44972.682815]  --- level:6 rd:4 wd:4
[44972.682817]  disk 0, o:1, dev:sdb
[44972.682819]  disk 1, o:1, dev:sdc
[44972.682820]  disk 2, o:1, dev:sdd
[44972.682821]  disk 3, o:1, dev:sde

嘗試 mount /dev/md0 報告:

mount: wrong fs type, bad option, bad superblock on /dev/md0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

並且 dmesg

[44984.159908] EXT4-fs (md0): ext4_check_descriptors: Block bitmap for group 0 not in group (block 1318081259)!
[44984.159912] EXT4-fs (md0): group descriptors corrupted!

我不確定現在做什麼。建議?


輸出 dumpe2fs /dev/md0

dumpe2fs 1.42.8 (20-Jun-2013)
Filesystem volume name:   Atlas
Last mounted on:          /mnt/atlas
Filesystem UUID:          e7bfb6a4-c907-4aa0-9b55-9528817bfd70
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              244195328
Block count:              976756712
Reserved block count:     48837835
Free blocks:              92000180
Free inodes:              243414877
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      791
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stripe width:        2
Flex block group size:    16
Filesystem created:       Thu May 24 07:22:41 2012
Last mount time:          Sun May 25 23:44:38 2014
Last write time:          Sun May 25 23:46:42 2014
Mount count:              341
Maximum mount count:      -1
Last checked:             Thu May 24 07:22:41 2012
Check interval:           0 (<none>)
Lifetime writes:          4357 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      e177a374-0b90-4eaa-b78f-d734aae13051
Journal backup:           inode blocks
dumpe2fs: Corrupt extent header while reading journal super block

6
2018-05-26 10:55


起源


你的獎金問題的答案基本上是因為Windows在同一系統上從未對其他操作系統起到特別好的作用。 - α CVn
您是否擁有足夠的磁盤空間來製作構成RAID6陣列的所有設備的完整扇區副本?至少要留出你現在所擁有的東西,這樣你就可以進行實驗而不會有進一步損害的風險。 - α CVn
@MichaelKjörling,我決定繼續進行完整的磁盤恢復 /dev/sdd。到目前為止,它看起來很好,感謝目前為止的快速反應。如有興趣,請參閱更新以獲取詳細信息。 - swalog
如果這適合您,請記得寫一個適當的自我回答並接受它以造福社區。 - α CVn
將來,請先安裝Windows。總是。 Linux幾乎總是檢測Windows啟動加載器。如果您無法先安裝Windows,請先斷開所有其他硬盤驅動器(如您所述) - Canadian Luke


答案:


我有點驚訝 mdadm 首先使用該磁盤組裝陣列,但這是另一個故事。不幸的是,您的陣列可能不再處於可恢復狀態。

Linux軟件raid假定陣列是健康的(乾淨的),除非磁盤控制器發出讀或寫錯誤信號,如上所述 Linux raid wiki。 司機認為因為有很多 存儲在磁盤上的冗餘數據,以及硬盤和控制器之間的鏈接也使用錯誤檢測。

因此,您的四種情況(在RAID6模式下)甚至不會讀取奇偶校驗塊。

Raid6

覆蓋您的一個磁盤(在磁盤的角度)是一個完全有效的請求,並由您的磁盤完成,沒有錯誤。

現在,當您使用具有損壞數據的磁盤請求陣列重建時,您只需在整個陣列上傳播校正數據。

正確的想法是設置驅動器故障,然後將其添加回陣列。該陣列將在安全狀態下重建。


0
2017-08-23 12:47



謝謝你的答案。實際上,這對以後知道是有用的。我犯的最大錯誤是在重要之前不測試我的備份。事後看來,備份101。 - swalog