On 03/01/2017 10:02 AM, Wols Lists wrote: > Sorry to drag this up again, but where are these write intent bits > going to come from? And it's a backup. Why am I going to re-add, > unless I'm going to wipe the old backup and create a new one? Given your process below, it's moot. > And your way is more complicated - more room for sys-admin cock-up > :-) I strongly disagree. This procedure, as shown, is an admin cock-up: > mdadm --build /dev/mdbackup --device-count 2 /dev/md/home missing > ... hotplug sd-big ... > madam /dev/mdbackup --add /dev/sd-big > ... wait for sync to finish ... > mdadm --stop mdbackup > ... unplug sd-big ... Are you unmounting /dev/md/home while this is going on? If not, and there's any significant activity, your "backup" is corrupt. If you are unmounting, your data is unavailable for the duration of the resync. The corresponding procedure for logical volume in LVM would be: # lvcreate -n homesnaplv -s homelv --size 10g vg0 # dd if=/dev/vg0/homesnaplv of=/dev/sd-big bs=1M # lvremove /dev/vg0/homesnaplv Unlike your solution, the LVM snapshot won't be changing underneath you during the copy. The allocated size of the snapshot, shown as 10g above, only has to be big enough to accommodate the amount of writes to homelv while the dd is in progress. Also, LVM understands most mounted filesystems, and will invoke the proper kernel calls to briefly quiesce the filesystem for the snapshot, ensuring the filesystem copied out is consistent. But the user sees only a few tens or hundreds of milliseconds of hesitation and can keep going. Writes to homelv while the snapshot exists generate extra disk activity (to move the replaced blocks to the snapshot storage, with some metadata), but is otherwise invisible to the users. LVM is *made* for this. You should use it. Phil -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
