[linux-lvm] The feasibility of implementing an alternative snapshot approach
zkabelac at redhat.com
Mon Jan 9 22:18:36 UTC 2023
Dne 09. 01. 23 v 7:21 Zhiyong Ye napsal(a):
> Hi Zdenek,
> Thank you for your detailed answer.
> For the thin snapshot I will use the latest version of kernel and lvm for
> further testing. I want to use both snapshot methods (thin and thick) in the
> production environment. But if the thick snapshot is only still in the
> maintenance phase, then for thick lv I have to see if there is any other way
> to accomplish the snapshot function.
FYI - there are still some delays with up-streaming of the latest improvement
patches - so stay tuned for further speedup gains & IO throughput with thin
By the maintenance phase for old thick snapshot I mean - the development of
the existing thick snapshot target is basically done - the format is very
ancient and cannot be changed without major rewrite of the whole snapshot
target as such - and that's what we've made with newly introduced
thin-provisioning target which addressed many shortcomings of the old
> I use lvm mainly for virtualized environments. Each lv acts as a block device
> of the virtual machine. So I also consider using qemu's own snapshot feature.
> When qemu creates a snapshot, the original image used by the virtual machine
> becomes read-only, and all write changes are stored in the new snapshot. But
> currently qemu's snapshots only support files, not block devices.
Depending on the use-case it might matter to pick the best fitting chunk-size.
i.e. if the changes are 'localized' in the filesystem areas to match thin-pool
chunks (also selection of the filesystem itself might be part of equation
here) - even if you use snapshots a lot, you may eventually get better result
with bigger chunks like 128k or even 256k size instead of default 64K.
More information about the linux-lvm