On Mon, Aug 18, 2003 at 01:14:15AM +0200, Jan Niehusmann wrote:
> So I looked at the underlying devices, and both /dev/hda4 and /dev/md2 had
> a copy of the actual filesystem, only differing in the last 512K. This
> conforms to the fact that the mirroring was done for all but one 512K
> block. But these 512K are completely different (target device all zeroes).
Please confirm which kernel you are using, and the device-mapper
patch(es) you applied. [patches/linux-2.4.2?* from the 1.00.02
device-mapper tarball?]
Some more diagnostics:
check that you have 'activation = 1' and 'level = 7' in the log{}
section of lvm.conf and if not, recreate a problem pvmove application log
(The you put on the web seems incomplete)
['activation = 1' setting is only meant for use when diagnosing
problems like this - don't leave it there permanently]
> However, these are only the underlying devices. Looking at
> /dev/vgraid/lvol5 a little bit closer revealed that it contained parts
> of some other filesystem. Very strange. And worrying. I don't even want
> to know if writing to this LV would overwrite some unrelated partition.
Use dmsetup to see what's going on:
run 'dmsetup ls' to get a list of internal device names,
then 'dmsetup -v table <device_name_shown_in_ls>'
on all the relevant ones (e.g. vgraid-lvol5*)
After all the interruptions you've had, check the /dev/vgraid/lvol5
symlink (->/dev/mapper/vgraid-lvol5) & destination major/minor is
still right.
Check the current metadata (with vgcfgbackup) still looks right.
[Does it show pvmove(s) in progress, or is it clean again?]
Alasdair
--
agk@uk.sistina.com
_______________________________________________
linux-lvm mailing list
linux-lvm@sistina.com
http://lists.sistina.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
