[linux-lvm] The feasibility of implementing an alternative snapshot approach

Zdenek Kabelac 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 
provisioning)

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 
dm-snapshot target.

> 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.

Regards

Zdenek



More information about the linux-lvm mailing list