On Oct 26, 2006, at 3:17 PM, Paul LeoNerd Evans wrote:
I'm running kernel 2.6.17 using the lvm2 package currently in debian
testing (2.02.06-3). I use it to set up a VG containing two
PVs, /dev/sda2 and /dev/sdb2. I create a mirror LV using corelog:
lvcreate --mirror 1 --corelog ...
I create a filesystem on it, and populate it with files. I then try
testing how it copes with drive failures, by simulating a replaced
disk.
To do this, I zero out one of the sides using
dd if=/dev/zero of=/dev/sda2
This doesn't really reflect what would happen if you replaced a disk, I
don't think. With this, you are simply going around mirror's back to
write data to a device which it controls.
In real life, I think you would have a disk failure (which would force
you to run 'vgreduce --removemissing vg'), then you would insert a new
block device, pvcreate/vgextend/lvconvert.
(When dmeventd is properly running, it should take care of the steps
that are currently manual.)
Having done that, I do the usual restore method
pvcreate --uuid 'whatever' /dev/sda2
vgcfgrestore vg
vgchange -a y
And I note that it starts to resync the mirror. But it goes in the
"wrong" direction - sda2's PV is the master, but that's been zeroed
out.
sdb2's is the slave but contains the real data. The block copying goes
in
the wrong direction here, copying the master's zeroes over the good
data
in the slave.
Again, mirror has no idea that you did this. The act of dd'ing to an
underlying device is like dd'ing to a device under a file system - it
doesn't know you are doing it and causes corruption.
Is this a bug in the LVM2 tools, or the dm-mirror target, or what? Is
it
perhaps a limitation of --corelog; in which case, how can I protect
against that?
LVM2 mirroring is still a work in progress (trying to get the right
pieces upstream). Depending on the version of LVM2 and the kernel
patches you have, it may not work.
The use of --corelog simply means that the mirror device will be
resynchronized every time the device is activated. The persistent log
(disk log) tracks what resynchronization has been done and can avoid
all complete resyncs.
brassow
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
