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/
