Re: [linux-lvm] Any way to speed up activation of volumes with snapshots?

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 14.9.2015 v 21:16 Chris Friesen napsal(a):
> On 09/14/2015 12:47 PM, Zdenek Kabelac wrote:
>> Dne 14.9.2015 v 20:05 Chris Friesen napsal(a):
>>> Hi,
>>>
>>> I'm running a 3.10 kernel with LVM 2.02.95.
>>>
>>> I'm running into a problem where activating snapshots can take quite a long
>>> time, roughly one minute per 25GB of delta between the snapshot and the origin
>>> volume.  (See below for my test procedure.)
>>>
>>> I realize that my kernel/LVM aren't exactly bleeding edge, and I wondering
>>> whether more recent versions have done anything to speed up the activation
>>> process (like maybe making it more lazy-loaded rather than reading in a bunch
>>> of data up-front).
>>>
>>> If anyone is aware of such improvements, I'd appreciate it if you could point
>>> me at the appropriate changes.
>>
>> Hi
>>
>> There is NO way to accelerate your existing setup, other then placing delta on
>> SSD - the format of snapshot was meant to be used 'temporarily' - i.e. until
>> you
>> take backup of LV - but not for long-term multi-gigabyte case.
>>
>> This is major mis-use of this 'snapshot' feature - which repeats over and
>> over...
>>
>> If you want to use long-living snapshots - you need to use thin-provisioning,
>
> Thanks for the quick response.
>
> Presumably we would still have multi-GB of delta between the original volume
> and the snapshot, so what would make the activation of a thin-provisioned
> snapshot faster?  Is the metadata stored differently?

Yes - metadata are on separate device(LV) and are using b-trees.
So now you could i.e. chain snap-of-snap-of-snap...
Also snaps do not need to be active with origin and many other goodies.

Drawbacks - all data have to be in same pool and share same space,
so you can't run 'just' 'snapshot' out-of-space - whole pool is out-of-space.
Also min chunk size is 64K (instead of 4K for old-snap)

Anyway - try and play and see what performs better and suit your needs.


Zdenek