[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [linux-lvm] LVM corruption/diagnosis

Hi Radu, all,

> I hope this helps you debug the issue you had. It would also be
> interesting if you could try to zero the *original* LVM volume (the one
> that didn't work) and then restore the image once again and see if it
> works. It would prove (or disprove) my theory :)

Even though I still consider your theory (of zeroing the blocks before
restoring the image) the most plausible, something else showed up when I
looked at zeroing the partition (I have to wait restoring the image as
this is a production system).

The old LV apparently is still online/active and I cannot deactivate
it/take it offline even though I'm sure it is not in use. This is
something (with LVM2) I've seen before: LVs are marked to be in use (and
cannot be taken offline) even though none of the running VMs is using
the LV.

# lvchange -a n /dev/d/xm.wxp
LV d/xm.wxp in use: not deactivating

If something else is using the LV as well as the VM, it would be logical
that the VM experiences corruptions (even if it's running code from
Redmond :-P ).

I've tried using kpartx in the past (as suggested in some places) but
without much success. In the following list, d-xm.wxp is the old LV
(that no longer works [pre zeroing the blocks]), d-xm.wxp2 is the new LV
(that is currently in use) and I don't know what d-xm.wxp1 is...
possible the first partition d-xm.wxp that keeps it online?

brw-rw----  1 root disk 254, 22 2011-03-30 04:58 d-xm.wxp
brw-rw----  1 root disk 254, 24 2011-03-28 09:18 d-xm.wxp1
brw-rw----  1 root disk 254, 25 2011-04-01 05:56 d-xm.wxp2
# kpartx -d /dev/d/d-xm.wxp
failed to stat() /dev/d/d-xm.wxp
# kpartx -d /dev/d/d-xm.wxp1
failed to stat() /dev/d/d-xm.wxp1

I wouldn't know though what else could be using the LV and I am not
aware of any methods to find out... any suggestions?

best regards,

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]