[linux-lvm] Time needed for take a snapshot

[linux-lvm] Time needed for take a snapshot

[Gionatan Danti]

Hi list,
just for confirmation: is the time needed to take a snapshot constant, 
or does it depend on how many chunks are mapped in/by the specific thin 
pool and volume? In other workds, is snapshot create time O(1) or O(n)?

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

Re: [linux-lvm] Time needed for take a snapshot

[Zdenek Kabelac]

Dne 19. 01. 20 v 13:59 Gionatan Danti napsal(a):
> Hi list,
> just for confirmation: is the time needed to take a snapshot constant, or does 
> it depend on how many chunks are mapped in/by the specific thin pool and 
> volume? In other workds, is snapshot create time O(1) or O(n)?

Hi

Depends on what you are asking -  in lvm2 - unfortunately some parts of the 
code are sometimes even O(n^2) - so the more LVs are in VG - the 'heavier' the 
operation gets.

So having  thousands of LVs in a single VG will become probably your bottleneck.

The bTree mapping in kernel will probably be less problematic here.

Regards

Zdenek

Re: [linux-lvm] Time needed for take a snapshot

[Gionatan Danti]

Il 20-01-2020 10:22 Zdenek Kabelac ha scritto:
> So having  thousands of LVs in a single VG will become probably your 
> bottleneck.

Hi Zdenek, I was thinking more about having few LVs, but with different 
amount of data/mapping.

For example, is a very fragmented volume (ie: one written randomically) 
significantly slower to snapshot than an almost empty volume? I fully 
expect some small difference; however, if an empty volume take 0.2s and 
a fragmented one 20s, this would surely be significant.

Note that I never had such a slow snapshot, rather, even on aged and big 
volumes, it always take <1s. However, other experiences are welcome.

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

Re: [linux-lvm] Time needed for take a snapshot

[Zdenek Kabelac]

Dne 20. 01. 20 v 11:36 Gionatan Danti napsal(a):
> Il 20-01-2020 10:22 Zdenek Kabelac ha scritto:
>> So having� thousands of LVs in a single VG will become probably your 
>> bottleneck.
> 
> Hi Zdenek, I was thinking more about having few LVs, but with different amount 
> of data/mapping.
> 
> For example, is a very fragmented volume (ie: one written randomically) 
> significantly slower to snapshot than an almost empty volume? I fully expect 
> some small difference; however, if an empty volume take 0.2s and a fragmented 
> one 20s, this would surely be significant.
> 
> Note that I never had such a slow snapshot, rather, even on aged and big 
> volumes, it always take <1s. However, other experiences are welcome.

Yep - kernel metadata 'per thin LV' are reasonably small - so even for big 
thin devices it still should fit within your time boundaries.
(effectively thin snapshot just increases 'mapping' sharing between origin and 
its snapshot - so the time needed depends on how many bTree nodes needs to be 
updated - so if you would manage to create heavily fragmented multi TiB 
thinLV, the time depends on speed of you metadata device - as long as device 
is fast (i.e. >= SSD) - operation should be quick.
But ATM there is no scientific proof for the worst case scenario.

Regards

Zdenek

Re: [linux-lvm] Time needed for take a snapshot

[Gionatan Danti]

Il 20-01-2020 15:40 Zdenek Kabelac ha scritto:
> Yep - kernel metadata 'per thin LV' are reasonably small - so even for
> big thin devices it still should fit within your time boundaries.
> (effectively thin snapshot just increases 'mapping' sharing between
> origin and its snapshot - so the time needed depends on how many bTree
> nodes needs to be updated - so if you would manage to create heavily
> fragmented multi TiB thinLV, the time depends on speed of you metadata
> device - as long as device is fast (i.e. >= SSD) - operation should be
> quick.
> But ATM there is no scientific proof for the worst case scenario.

Well, I'll do some tests and update here if finding anything 
interesting.
Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8