0

I've successfully configured a raid 1 array with mdadm. Both drives have a raid partition and an uefi partition with GRUB installed.

When I execute "cat /proc/mdstat", I have a working array with 2x UU.

However, my array is gone when I do the following :

  1. disconnect sda's sata & power cable
  2. Boot degraded with sdb, shutdown
  3. Then connect sda again, disconnect sdb
  4. Boot degraded with sda, shutdown
  5. connect both disks again and run cat /proc/mdstat
  6. result = array gone :

    md0 : active raid1 sdb2[1]
          3905908736 blocks super 1.2 [2/1] [_U]
          bitmap: 11/30 pages [44KB], 65536KB chunk
    

I did this twice and I'm fed up with this behaviour. At this point I have to recreate the array and re-add sda. But the rebuilding of the array takes ages since it are 4TB drives.

Maby something important I should mention is that only one drive boots (sda) properly in degraded mode . The other one (sdb) boots in emergency mode. But I figured out how to fix this. The problem is in the /etc/fstab file.

UUID=64C3-7807  /boot/efi       vfat    umask=0077      0       1

It points to the UUID of sda. I can boot sdb normally when changing the UUID in the fstab file. Perhaps I can put both drives in fstab ?

So what's happening here? Or is there a way to re-add sda quickly ?

  • did you do mdadm --detail --scan >> /etc/mdadm/mdadm.conf after setting it up? – George Udosen Nov 21 '18 at 19:36
  • Yes, the array was added in the mdadm.conf file. I just figured out running the mdadm with --re-add instead of --add, rebuilds the array very fast. But this is not a permanent solution. – maarten Nov 21 '18 at 19:52
  • What do you expect to happen? – vidarlo Nov 21 '18 at 19:57
  • I expect the array to just work like before. So it's normal that the array just removes a disk after reconnecting both ? It does not see that both disks are back again ? – maarten Nov 21 '18 at 20:02
  • You have two disks with different metadata. See my answer for details. What you suggest would be an potentially destructive behavior in some cases. – vidarlo Nov 21 '18 at 20:10
0
  1. disconnect sda's sata & power cable
  2. Boot degraded with sdb, shutdown
  3. Then connect sda again, disconnect sdb
  4. Boot degraded with sda, shutdown

When you do this, the two drives will have differences. This will be marked by differing timestamps in the metadata. It's intentional and expected behavior. You don't have an consistent array any more, and consequently one drive will be marked as failed.

Linux has no way of knowing which drive is correct, so you have to manually add the drive to array. It could be that one drive actually failed, but you managed to boot from it, as the error is far from the area used by system files. It may have the newest signature, yet have a fault.

Or it may be the other way around. This should not be automated - that risks overwriting data you want to keep.

I am not sure how you expect it to behave, but this is the sensible way for an RAID 1-array to behave when you have inconsistencies: manual resolution.

As md is a block layer protocol, it has to write everything from one drive to the other to guarantee that the content is indeed equal. If you want higher level (e.g. file system level) redundancy, you may have a look at btrfs or zfs, which both has advanced features in this direction.

Anyway, this sounds like an x-y problem, so I'm a bit curious as to why you even want this to work - because I don't think RAID is meant to solve whatever problem you are trying to solve.

  • That makes sense ... probably tiny differences that occur on both disks when booting each of them degraded – maarten Nov 21 '18 at 20:28
  • @maarten log files, just to name one thing that's routinely overwritten.... – vidarlo Nov 21 '18 at 20:30
  • using --re-add instead of --add should be OK I guess ? It fixes the array in a minute – maarten Nov 21 '18 at 20:31
  • Yes. That will work. Man page for mdadm gives you information about --re-add – vidarlo Nov 21 '18 at 20:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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