mdadm: Win7-install đã tạo phân vùng khởi động trên một trong các ổ RAID6 của tôi. Làm thế nào để xây dựng lại?

Vấn đề của tôi xảy ra khi tôi cố cài đặt Windows 7 trên ổ SSD của chính nó. Hệ điều hành Linux mà tôi đã sử dụng có kiến ​​thức về hệ thống RAID phần mềm nằm trên ổ SSD mà tôi đã ngắt kết nối trước khi cài đặt. Điều này là để các cửa sổ (hoặc tôi) sẽ vô tình làm hỏng nó.

Tuy nhiên, và khi nhìn lại, thật ngu ngốc, tôi đã để các đĩa RAID được kết nối, nghĩ rằng các cửa sổ sẽ không vô lý đến mức gây rối với ổ cứng mà nó coi là không gian chưa được phân bổ.

Con trai là tôi sai! Sau khi sao chép các tệp cài đặt vào SSD (như mong đợi và mong muốn), nó cũng tạo một ntfsphân vùng trên một trong các đĩa RAID. Cả bất ngờ và hoàn toàn không mong muốn! .

Tôi đã thay đổi SSDmột lần nữa và khởi động trong linux. mdadmDường như không có bất kỳ vấn đề nào khi lắp ráp mảng như trước đây, nhưng nếu tôi cố gắn mảng, tôi nhận được thông báo lỗi:

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!

Sau đó, tôi đã sử dụng qpartedđể xóa ntfsphân vùng vừa tạo /dev/sddđể nó phù hợp với ba phân vùng còn lại /dev/sd{b,c,e}và yêu cầu đồng bộ lại mảng của tôi vớiecho repair > /sys/block/md0/md/sync_action

Điều này mất khoảng 4 giờ và sau khi hoàn thành, dmesgbáo cáo:

md: md0: requested-resync done.

Một chút ngắn gọn sau một nhiệm vụ 4 giờ, mặc dù tôi không chắc là nơi các tệp nhật ký khác tồn tại (tôi dường như cũng đã làm rối cấu hình sendmail của mình). Trong mọi trường hợp: Không có thay đổi nào được báo cáo theo mdadm, mọi thứ đều được kiểm tra. mdadm -D /dev/md0vẫn báo cáo:

        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

Đang cố gắn nó vẫn báo cáo:

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

và dmesg:

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

Tôi hơi không chắc chắn nên tiếp tục từ đâu và thử công cụ "để xem nó có hoạt động không" là một điều quá rủi ro đối với tôi. Đây là những gì tôi đề nghị tôi nên cố gắng làm:

Nói mdadmrằng /dev/sdd(cái mà windows ghi vào) không còn đáng tin nữa, giả vờ nó mới được giới thiệu lại vào mảng và xây dựng lại nội dung của nó dựa trên ba ổ đĩa khác.

Tôi cũng có thể hoàn toàn sai trong các giả định của mình, rằng việc tạo ntfsphân vùng trên /dev/sddvà xóa sau đó đã thay đổi một cái gì đó không thể được sửa theo cách này.

Câu hỏi của tôi: Giúp đỡ, tôi nên làm gì? Nếu tôi nên làm những gì tôi đề nghị, làm thế nào để tôi làm điều đó? Từ việc đọc tài liệu, vv, tôi sẽ nghĩ có thể:

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

Tuy nhiên, các ví dụ về tài liệu cho thấy /dev/sdd1, điều này có vẻ lạ đối với tôi, vì không có phân vùng nào có liên quan đến linux, chỉ là không gian chưa được phân bổ. Có thể các lệnh này sẽ không hoạt động mà không có.

Có lẽ thật hợp lý khi phản chiếu bảng phân vùng của một trong những thiết bị đột kích khác chưa từng chạm vào trước đó --re-add. Cái gì đó như:

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

Câu hỏi thưởng: Tại sao cài đặt Windows 7 sẽ làm một cái gì đó rất ... nguy hiểm?

Cập nhật

Tôi đã đi trước và đánh dấu /dev/sddlà bị lỗi, và loại bỏ nó (không phải vật lý) khỏi mảng:

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

Tuy nhiên, cố gắng --re-add đã không được phép:

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

--add, đã ổn

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

mdadm -D /dev/md0bây giờ báo cáo nhà nước như clean, degraded, recovering, và /dev/sddnhư spare rebuilding.

/proc/mdstat cho thấy tiến trình phục hồi:

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 cũng cho thấy sản lượng dự kiến:

│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|>                                                ||

Nó có vẻ tốt cho đến nay. Bắt chéo ngón tay của tôi thêm năm giờ nữa :)

Cập nhật 2

Sự phục hồi của /dev/sddthành phẩm, với dmesgđầu ra:

[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/md0Báo cáo cố gắng :

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

Và trên 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!

Tôi không chắc phải làm gì bây giờ. Gợi ý?

Đầu ra của 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

Tôi hơi ngạc nhiên khi mdadmlắp ráp mảng bằng đĩa đó ngay từ đầu, nhưng đây là một câu chuyện khác. Thật không may, mảng của bạn có thể không còn trong trạng thái có thể phục hồi.

Cuộc đột kích phần mềm Linux giả định rằng mảng đó khỏe (sạch), trừ khi lỗi đọc hoặc ghi được báo hiệu bởi bộ điều khiển đĩa, như đã giải thích trên wiki cuộc đột kích Linux . Trình điều khiển giả định rằng vì có rất nhiều dữ liệu dư thừa được lưu trữ trên đĩa và liên kết giữa đĩa cứng và bộ điều khiển cũng sử dụng phát hiện lỗi.

Vì vậy, bốn tình huống của bạn (trong chế độ RAID6) các khối chẵn lẻ thậm chí không được đọc.

Ghi đè một trong các đĩa của bạn là (theo quan điểm của đĩa) là một yêu cầu hoàn toàn hợp lệ và được đĩa của bạn hoàn thành mà không có lỗi.

Bây giờ khi bạn yêu cầu xây dựng lại mảng bằng đĩa có dữ liệu bị hỏng, bạn chỉ cần trải dữ liệu bị hỏng trên toàn mảng.

Suy nghĩ đúng phải làm là đặt ổ đĩa bị lỗi, sau đó thêm nó trở lại mảng. Các mảng sẽ được xây dựng lại trong một trạng thái an toàn.