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

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 11.9.2017 v 12:55 Xen napsal(a):
> Zdenek Kabelac schreef op 11-09-2017 12:35:
> 
>> As thin-provisioning is about 'promising the space you can deliver
>> later when needed'� - it's not about hidden magic to make the space
>> out-of-nowhere.
>> The idea of planning to operate thin-pool on 100% fullness boundary is
>> simply not going to work well - it's� not been designed for that
>> use-case
> 
> I am going to rear my head again and say that a great many people would 
> probably want a thin-provisioning that does exactly that ;-).
> 

Wondering from where they could get this idea...
We always communicate clearly - do not plan to use 100% full unresizable 
thin-pool as a part of regular work-flow - it's always critical situation 
often even leading to system's reboot and full check of all volumes.

> I mean you have it designed for auto-extension but there are also many people 
> that do not want to auto-extend and just share available resources more flexibly.
> 
> For those people safety around 100% fullness boundary becomes more important.
> 
> I don't really think there is another solution for that.
> 
> I don't think BTRFS is really a good solution for that.
> 
> So what alternatives are there, Zdenek? LVM is really the only thing that 
> feels "good" to us.
> 

Thin-pool  needs to be ACTIVELY monitored and proactively either added more PV 
free space to the VG or eliminating  unneeded 'existing' provisioned blocks 
(fstrim,  dropping snapshots, removal of unneeded thinLVs.... -  whatever 
comes on your mind to make a more free space in thin-pool  - lvm2 fully 
supports now to call 'smart' scripts directly out of dmeventd for such action.


It's illusion to hope anyone will be able to operate lvm2 thin-pool at 100% 
fullness reliable - there should be always enough room to give 'scripts'
reaction time to gain some more space in-time  - so thin-pool can serve free 
chunks for provisioning - that's been design - to deliver blocks when needed,
not to brake system

> Are there structural design inhibitions that would really prevent this thing 
> from ever arising?

Yes, performance and resources consumption.... :)

And there is fundamental difference between full 'block device' sharing
space with other device - compared with single full filesystem - you can't 
compare these 2 things at all.....


Regards


Zdenek