Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have two drives in a mirror (linux sw raid/mdadm); one drive somehow left the mirror in the past and its content is now several days old. At this moment, I'm using degraded mirror (with one drive missing) and considering:

  • clone uptodate drive to the second one with dd
  • add second drive and resync, but I don't know how resync process works and which data will be overwritten (there are LVM volumes on that mirror)

I think dd is safe way, anyway I'm interested in how resychronization works.

share|improve this question

2 Answers 2

up vote 6 down vote accepted

The right thing to do is something like mdadm --add /dev/md0 /dev/sdb1. Use the correct array in place of md0 and the correct partition in place of sdb1.

The key thing is the array is running. Its completely unambiguous which data to copy: the data that is currently running. If you have bitmaps enabled, the resync will be fairly fast as it'll only copy what has changed. Otherwise, it'll copy everything.

If you are extremely paranoid—or you're worried that your disk system may have lost writes, and the bitmap may not be correct—and don't mind forcing a full copy, you can wipe the superblock on the disk you're about to add using mdadm --zero-superblock /dev/sdb1 (once again, use the correct partition).

If the array wasn't currently running (e.g., if this were a rebuild on assemble from an unclean shutdown), then the decision on what to copy is made using the update count fields stored in the superblock. Its possible that it may refuse to re-add a disk with a too-high update count (forcing you to zero the superblock), but it won't overwrite the active data.

If you were to use the dd approach, then: (a) You'd wind up copying the superblock, and you'd wind up with two disk 1s (the superblock stores the position of the disk in the array); (b) you'd have an inconsistent copy, unless you had the array stopped (or maybe in read-only mode) during the copy. (And then, to fix a and b, you'd wipe the superblock and let mdraid copy the data, as above).

In short, when you decide to use mdraid (or any other RAID), you give management of redundancy to it. You almost never want to go around it. Same with LVM: if you want to move data around, you use pvmove, etc. You don't use dd.

PS: "one drive somehow left the mirror" is not something you should accept. There are logs; figure out why it left the mirror. With even a half-recent kernel, bad blocks don't drop drives out anymore, so random drive drops should not happen. Check smart status, etc.

share|improve this answer
    
+1 for figuring out why the drive was dropped. –  psusi Feb 22 '13 at 14:26
    
I wasn't aware that there is no --assume-clean for --add. One might say: Why should something like that exist... :-) So in order to make a correct sync with dd one would have to stop the array, copy the volume, zero the superclocks and create a new array from the two volumes with --assume-clean and correct the UUID afterwards with --assemble (the device UUIDs will change but that should not matter). Right now I cannot imagine a situation in which that would make sense. –  Hauke Laging Feb 22 '13 at 15:48
    
@HaukeLaging well, if you do a --create, I think you can specify the UUID to use. Or use --update later—sometimes the UUID is used. E.g., in your /etc/mdadm/mdadm.conf file, your initramfs, etc. Of course, its much better to not go around mdraid. –  derobert Feb 22 '13 at 16:51
    
ad PS, no it's not acceptable, same as when colleague unplug this machine from power because he thought "this is another computer". Anyway thank you, now I know what I want to. –  dmnc Feb 22 '13 at 21:53
    
I found that drive is bad, a few failures are in the log and resync now killed it definitely. –  dmnc Feb 23 '13 at 7:00

If you have configured your RAID-1 to use a bitmap (see man page) then --re-add is a lot faster because just the areas written after the connection breaking have to be written.

In any way (even without a bitmap an full synchronization) you can more easily than with dd configure the sync speed via /sys/block/md0/md/sync_speed_*

Synchronization with dd would require you to make the active disks read-only during that time, too. So you really should let make the md driver the job. And if you haven't done yet: Add a bitmap.

share|improve this answer
    
thank you, this is good point. Anyway I still don't know if resync will overwrite "old" drive with "new" data or if I can loose my new data by overwriting them from "old" drive, I you understand me... –  dmnc Feb 22 '13 at 13:16
1  
I understand you but the RAID code is not completely stupid. –  Hauke Laging Feb 22 '13 at 13:18

Your Answer

 
discard

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.