[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-lvm
Subject:    Re: [linux-lvm] LVM corruption/diagnosis
From:       Jan Bakuwel <jan.bakuwel () omiha ! com>
Date:       2011-04-07 8:31:52
Message-ID: 4D9D7678.20906 () omiha ! com
[Download RAW message or body]

Hi Radu,


> I don't think that mapping the partitions with kpartx could affect the
> VM (that reads/writes to the LV directly).

I don't think so either but then I didn't think that not zeroing
unallocated block might make a difference either :-)

> But what I know for sure is that when you map a block device with
> kpartx, the "partition" devices that kpartx creates under /dev/mapper
> have different read/write caches than the original block device (the LV
> in your case).
>
> One issue that I experienced is that when you write data to a kpartx
> mapped device (partition) and some (or all) of the blocks that you write
> happen to be in the read cache of the original block device (the LV),
> then you'll read "old" data from the LV, even if you first unmap the
> partitions with kpartx -d.


The VM is the only entity accessing the LV.


> This issue can be simply addressed by using "blockdev --flushbufs" on
> the LV, after you do "kpartx -d" and before you use the LV (start the VM
> for instance).
>
> What type of image are you restoring? The whole LV (including its
> partition table) or just the partition inside the LV (perhaps with
> ntfsclone)? Because if you're restoring the partition (and not using
> "kpartx -d" and "blockdev --flushbufs", it's very likely that you ran
> into caching issues.


A full disc image including the partition table, boot block etc.

Will let you know how it goes.

best regards,
Jan

_______________________________________________
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/
[prev in list] [next in list] [prev in thread] [next in thread]