2

In a RAID 1 config with MDADM, which device is the master device during the initialization process?

In a RAID 1 config with 2 devices, presumably (?) one device acts as a master and the other as a slave when the initial sync process between the two devices is done. (To make the binary data the same.)

In a config with more than 2 devices, there are presumably multiple slave devices. From which /dev/sdX device is data copied from?

Improve this question

1 Answer 1

Reset to default
4

For mdadm --create and RAID 1, it's usually the first device copied to the second one. However, there is no guarantee for this.

After all, mdadm --create creates a new RAID from scratch with no data on it, so it does not matter which direction things are copied for the initial sync. Any data you want to be there, you have to write after creation.

If you wish to force the matter, you can create a degraded RAID and add the other drive afterwards:

mdadm --create /dev/md100 --level=1 --raid-devices=2 missing /dev/sdy1
mdadm --manage /dev/md100 --add /dev/sdx1

In this fashion the sync would go from /dev/sdy1 being the only drive in the RAID, to /dev/sdx1 which was added afterwards.

Even then, you can not rely on what data will be on the RAID.

Using mdadm --create for data recovery purposes is possible, but only if you know what you are doing. Basically this can be made to work by circumstance, it's not designed for this purpose.

In RAID 1 there is also the option to mark individual drives as write-mostly, which will mostly avoid reading from this drive as much as possible (but not completely). This can help offset some performance penalty in an array where one drive is noticably slower than the other.

Improve this answer
7
  • Interesting answer. I asked because I was a bit puzzled as to why the drives undergo a sync process at all, and why it isn't simply the case that all zeros are written to both drives to initialize them?
    – user3728501
    Commented Oct 11, 2020 at 22:30
  • Essentially - this answer still leaves me puzzled as to the behaviour or mdadm
    – user3728501
    Commented Oct 11, 2020 at 22:31
  • 2
    Writing zeroes is complicated. The resync is a background task, the RAID itself can be used right away. If this background task wrote zeroes, instead of the data already there, it would also zero out data written after the creation. So for writing zeroes you'd then have to start tracking written regions. It would also be a separate code path from what you need in an actual after-failure-resync where duplicating existing data is the primary purpose. Much easier to let the same code handle both creation and resync the same way.
    – frostschutz
    Commented Oct 11, 2020 at 22:48
  • 1
    No, you just can't rely on it. It will be data of /dev/sdy1 at some offset that mdadm chose for you. This offset might change, or mdadm might decide to wipe some data (like lvcreate and others do), or ... it's not documented that there will be data, so mdadm can do whatever it wants here.
    – frostschutz
    Commented Oct 12, 2020 at 9:14
  • 1
    So if you had a filesystem on /dev/sdy1 and then mdadm --create, the filesystem will be gone, metadata overwritten, /dev/md100 will start at offset 128M for example which makes it useless as a filesystem. You could use metadata 1.0 at end of disk, but then end of filesystem will be cut off. Either way the result is corrupt and additional steps are required to make such tricks work. mdadm --create creates new arrays without data on them; converting belatedly to raid, recovering damaged raid metadata etc. can be done only if you know how, it's not official feature
    – frostschutz
    Commented Oct 12, 2020 at 9:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .