Re: [linux-lvm] LVM corruption/diagnosis

[Jan Bakuwel <jan.bakuwel@omiha.com>]

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