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?

user3728501
  • 867
  • 13
  • 33

1 Answers1

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.

frostschutz
  • 47,228
  • 5
  • 112
  • 159
  • 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 Oct 11 '20 at 22:30
  • Essentially - this answer still leaves me puzzled as to the behaviour or mdadm – user3728501 Oct 11 '20 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 Oct 11 '20 at 22:48
  • Yes that's a good point actually – user3728501 Oct 11 '20 at 23:22
  • _"Even then, you can not rely on what data will be on the RAID"_: as far as I can tell, the `/dev/md100` array in your example would also be started by default upon creation, and all the data it contains would therefore be immediately accessible. Are you saying that a later `--add` may change that data? – fra-san Oct 12 '20 at 09:05
  • 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 Oct 12 '20 at 09: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 Oct 12 '20 at 09:22