Re: [External] Re: The feasibility of implementing an alternative snapshot approach

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Zdenek,

Thank you for your patience and explanations. I learned a lot from our discussions and thank you again for your help.

Regards

Zhiyong

On 1/10/23 6:18 AM, Zdenek Kabelac wrote:
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


_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux