[linux-lvm] Reserve space for specific thin logical volumes
Zdenek Kabelac
zkabelac at redhat.com
Mon Sep 11 11:20:51 UTC 2017
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
More information about the linux-lvm
mailing list