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

When a hard disk drive in one of my Linux machines failed, I took the opportunity to migrate from RAID5 to a 6-disk software RAID6 array.

At the time of the migration I did not have all 6 drives - more specifically the fourth and fifth (slots 3 and 4) drives were already in use in the originating array, so I created the RAID6 array with a couple of missing devices. I now need to add those drives in those empty slots. Using mdadm --add does result in a proper RAID6 configuration, with one glitch - the new drives are placed in new slots, which results in this /proc/mdstat snippet:

md0 : active raid6 sde1[7] sdd1[6] sda1[0] sdf1[5] sdc1[2] sdb1[1]
      25185536 blocks super 1.0 level 6, 64k chunk, algorithm 2 [6/6] [UUUUUU]

mdadm -E verifies that the actual slot numbers in the device superblocks are correct, yet the numbers shown in /proc/mdstat are still weird.

I would like to fix this glitch, both to satisfy my inner perfectionist and to avoid any potential sources of future confusion in a crisis. Is there a way to specify which slot a new device should occupy in a RAID array?


I have verified that the slot number persists in the component device superblock. For the version 1.0 superblocks that I am using that would be the dev_number field as defined in include/linux/raid/md_p.h of the Linux kernel source. I am now considering direct modification of said field to change the slot number - I don't suppose there is some standard way to manipulate the RAID superblock?


To modify the slot assignments in the device superblock I would need to do the following:

  1. Modify dev_number
  2. Modify the dev_roles array to mark the old slot as empty and place the proper role at the new slot
  3. Re-compute the superblock checksum

(1) and (2) are relatively simple and can be automated via a script or small program. (3) started to push things a little - I would have to rip the superblock checksum code from the md driver, modify it to work with a userspace program and hope for the best.

Rather than spend my time debugging a C application and risk killing my arrays with a bug, I decided to try to trick md/mdadm into doing my work for me, as mentioned in my answer. This seems to have worked, although it may still have a degree of risk...

share|improve this question
Do the slot numbers persist after completely stopping and recreating md0 (or simply, a clean boot)? – Joshua Hoblitt Nov 11 '12 at 19:19
If by recreating you mean mdadm --create then I would guess not, since that means rebuilding the array from raw data. If you mean mdadm --assemble then yes, the numbers seem to persist through an mdadm --stop/mdadm --assemble cycle... – thkala Nov 11 '12 at 19:23
Does this behavior bring you any troubles? It seems harmless to me – Kamil Šrot Nov 11 '12 at 19:59
@KamilŠrot: The array is fully functional, so I suppose it could be deemed harmless. That said, it is counter-intuitive and it lays to waste all my efforts to keep a correspondence between disk bays and RAID slots so that drives can be easily replaced. I would now have to keep a file with drive serial numbers and RAID slots, to avoid confusion... – thkala Nov 11 '12 at 20:41
@thkala makes definitely sense - I would suggest to get some better identification of the drive. eg. find out the PCI id of each bay (what does ls /dev/disk/by-path say?). I also noted somewhere "Location" property for hard drive, however I don't remember if it can solve your problem... – Kamil Šrot Nov 11 '12 at 20:57

Your Answer


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

Browse other questions tagged or ask your own question.