* [linux-lvm] Time needed for take a snapshot
@ 2020-01-19 12:59 Gionatan Danti
2020-01-20 9:22 ` Zdenek Kabelac
0 siblings, 1 reply; 5+ messages in thread
From: Gionatan Danti @ 2020-01-19 12:59 UTC (permalink / raw)
To: linux-lvm
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] Time needed for take a snapshot
2020-01-19 12:59 [linux-lvm] Time needed for take a snapshot Gionatan Danti
@ 2020-01-20 9:22 ` Zdenek Kabelac
2020-01-20 10:36 ` Gionatan Danti
0 siblings, 1 reply; 5+ messages in thread
From: Zdenek Kabelac @ 2020-01-20 9:22 UTC (permalink / raw)
To: LVM general discussion and development, Gionatan Danti
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] Time needed for take a snapshot
2020-01-20 9:22 ` Zdenek Kabelac
@ 2020-01-20 10:36 ` Gionatan Danti
2020-01-20 14:40 ` Zdenek Kabelac
0 siblings, 1 reply; 5+ messages in thread
From: Gionatan Danti @ 2020-01-20 10:36 UTC (permalink / raw)
To: Zdenek Kabelac; +Cc: LVM general discussion and development
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] Time needed for take a snapshot
2020-01-20 10:36 ` Gionatan Danti
@ 2020-01-20 14:40 ` Zdenek Kabelac
2020-01-20 15:54 ` Gionatan Danti
0 siblings, 1 reply; 5+ messages in thread
From: Zdenek Kabelac @ 2020-01-20 14:40 UTC (permalink / raw)
To: LVM general discussion and development, Gionatan Danti
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [linux-lvm] Time needed for take a snapshot
2020-01-20 14:40 ` Zdenek Kabelac
@ 2020-01-20 15:54 ` Gionatan Danti
0 siblings, 0 replies; 5+ messages in thread
From: Gionatan Danti @ 2020-01-20 15:54 UTC (permalink / raw)
To: Zdenek Kabelac; +Cc: LVM general discussion and development
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-01-20 15:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-19 12:59 [linux-lvm] Time needed for take a snapshot Gionatan Danti
2020-01-20 9:22 ` Zdenek Kabelac
2020-01-20 10:36 ` Gionatan Danti
2020-01-20 14:40 ` Zdenek Kabelac
2020-01-20 15:54 ` Gionatan Danti
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).