Re: [linux-lvm] Reserve space for specific thin logical volumes

[Gionatan Danti <g.danti@assyoma.it>]

Il 13-09-2017 01:31 Zdenek Kabelac ha scritto:
> It's not just about 'complexity' in frame work.
> You would lose all the speed as well.
> You would significantly raise-up  memory requirement.
> 
> There is very good reason complex tools like  'thin_ls' are kept in
> user-space  outside of kernel   - with  'dm'  we tend to have simpler
> kernel logic
> and complexity should stay in user-space.
> 
> And of course - as pointed out - the size of your 'reserve' is so
> vague  :) and could potentially present major portion of you whole
> thin-pool size without any extra benefit (as obviously any reserve
> could be too small unless you 'reach' fully provisioned state :)
> 
> i.e. example:
> 10G thinLV  with  1G chunks -  single byte write may require full 1G 
> chunk...
> so do you decide to keep 10 free chunks in reserves ??

What was missing (because I thought it was implicit) is that I expect 
snapshot to never change - ie: they are read-only.
Anyway, I was not writing about "resevers" - rather, to 
preassign/preallocate the required space to a specific volume.
A fallocate on a otherwise thinly provisioned volume, if you like.

> Supposedly:
> 
> lvmconfig --typeconfig full --withversion
> 
>         # Available since version 2.2.89.
>         thin_pool_autoextend_threshold=70
> 
> 
> However there were some bugs and fixes - and validation for not
> allowing to create new thins - so do not try anything below 169 and if
> you can
> go with 173....
> 

Ah! I was not thinking about thin_pool_autoextend_threshold! I tried 
with 166 (for now) and I don't see any major problems. However, I will 
surely upgrade at the first opportunity!

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