Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a 6 device raid 5 array which had 1 disk go bad and then due to a power outage, the machine shutdown and when it started all the disks were showing up as spares with the following mdadm -E output.

    Magic : a92b4efc
  Version : 1.2
  Feature Map : 0x0
   Array UUID : b480fe0c:c9e29256:0fcf1b0c:1f8c762c
     Name : GATEWAY:RAID5_500G
Creation Time : Wed Apr 28 16:10:43 2010
   Raid Level : -unknown-
 Raid Devices : 0

Avail Dev Size : 976768002 (465.76 GiB 500.11 GB)
Used Dev Size : 976765954 (465.76 GiB 500.10 GB)
  Data Offset : 2048 sectors
 Super Offset : 8 sectors
        State : active
  Device UUID : a8499a91:628ddde8:1cc8f4b9:749136f9

  Update Time : Sat May 19 23:04:23 2012
 Checksum : 9950883c - correct
   Events : 1

 Device Role : spare
 Array State :  ('A' == active, '.' == missing)`

This md device was part a Physical Volume for a LVM Volume Group.

I am trying to recreate the array using mdadm --create --assume-clean using 1 device as missing. I am checking if the device is getting created correctly by checking the UUID of the created device which would match if the device gets created correctly.

I have tried a few combinations of the disk order that I believe is right however I think I'm getting tripped up by the fact that the mdadm I used to create this md device was some 2.x series and now we are on 3.x (and I may have taken some of the defaults originally which I don't' remember) What all 'defaults' have changed over the versions so I can try those? Like chunk size? Can we manually configure the super/data offset? Are those significant when we do an mdadm --create --assume-clean?

Thanks, Anshu

share|improve this question
up vote 1 down vote accepted

Although in the best of all worlds mdadm should be able to detect your superblock format version when assembling or examining, you could try explicitly specifying an older superblock format version using the -e 0.90 parameter to mdadm and see what --examine has to say about that.

The superblock offset has a hardcoded position relating to the end of the device (in your case the partition), if the device's end has been moved (i.e. by changing the partition size or doing a raw-copy to a larger disk), mdadm would be unable to locate the correct copy.

It also looks a bit like your superblocks were messed with - if this is the case, you would not be able to "assemble" without some manual work. You should check all your drives for a valid superblock - there might be a copy somewhere which would spare you a lot of trial-and-error when re-building the MD array.

The general approach to recovery would be using mdadm --build with a chunk size of 64K (the old mdraid default, it changed to 512K later), the number of your devices and your presumed RAID level as the constant parameters and shuffling the device order unless you get a working filesystem. Needless to say that you should do this with copies of your HDD's data so you would not irrevocably change data by issuing an inexpert command.

share|improve this answer
Thanks a ton, I will first try different superblocks in my examine and then different cluster sizes that you have suggested ...unfortunately working on a full copy of my raid cluster is not feasible (needed raid 5 for size as well as redundancy :) Can you suggest which sectors (via dd) that I can make into sparse block files so I can work off those...atleast that way I can work off smaller sized files? Also, how can I check that there may be a copy somewhere? when I tried to reconstruct using --create --assume-clean I assumed it was 1.2 metadata – eskhool Jun 26 '12 at 8:52
Awesome link btw...very clearly documented page. – eskhool Jun 26 '12 at 8:59
@eskhool If you've used --create you would have overwritten the superblock If you can't copy the data, you might want to try setting the "read-only" bit for the affected devices by issuing hdparm -r 1 /dev/sd<X>. Obviously nothing can be written to the device then - you would not be able to change MD metadata (--create would not work, but you should yet be able to use --build), filesystem mounts would only work read-only and you would not be able to fsck unless you change back. I do not think you would have any luck by creating sparse files - too error-prone for reliable results. – the-wabbit Jun 28 '12 at 10:47

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.