[linux-lvm] Reserve space for specific thin logical volumes
zkabelac at redhat.com
Wed Sep 13 19:35:40 UTC 2017
Dne 13.9.2017 v 20:43 Xen napsal(a):
> There is something else though.
> You cannot set max size for thin snapshots?
We are moving here in right direction.
Yes - current thin-provisiong does not let you limit maximum number of blocks
individual thinLV can address (and snapshot is ordinary thinLV)
Every thinLV can address exactly LVsize/ChunkSize blocks at most.
> This is part of the problem: you cannot calculate in advance what can happen,
> because by design, mayhem should not ensue, but what if your predictions are off?
Great - 'prediction' - we getting on the same page - prediction is big
> Being able to set a maximum snapshot size before it gets dropped could be very
You can't do that IN KERNEL.
The only tool which is able to calculate real occupancy - is user-space
So all you need to do is to use the tool in user-space for this task.
> This behaviour is very safe on non-thin.
> It is inherently risky on thin.
>> (I know there are already some listed in this
>> thread, but I’m wondering about those folks that think the script is
>> insufficient and believe this should be more standard.)
> You really want to be able to set some minimum free space you want per volume.
> Suppose I have three volumes of 10GB, 20GB and 3GB.
> I may want the 20GB volume to be least important. The 3GB volume most
> important. The 10GB volume in between.
> I want at least 100MB free on 3GB volume.
> When free space on thin pool drops below ~120MB, I want the 20GB volume and
> the 10GB volumes to be frozen, no new extents for 30GB volume.
> I want at least 500MB free on 10GB volume.
> When free space on thin pool drops below ~520MB, I want the 20GB volume to be
> frozen, no new extents for 20GB volume.
> So I would get 2 thresholds and actions:
> - threshold for 3GB volume causing all others to be frozen
> - threshold for 10GB volume causing 20GB volume to be frozen
> This is easily scriptable and custom thing.
> But it would be nice if you could set this threshold in LVM per volume?
This is the main issue - these 'data' are pretty expensive to 'mine' out of
That's the reason why thin-pool is so fast and memory efficient inside the
kernel - because it does not need to all those details about how much data
thinLV eat from thin-pool - kernel target simply does not care - it only cares
about referenced chunks
It's the user space utility which is able to 'parse' all the structure
and take a 'global' picture. But of course it takes CPU and TIME and it's not
'byte accurate' - that's why you need to start act early on some threshold.
> But the most important thing is to freeze or drop snapshots I think.
> And to ensure that this is default behaviour?
Why you think this should be default ?
Default is to auto-extend thin-data & thin-metadata when needed if you set
threshold bellow 100%.
We can discuss if it's good idea to enable auto-extending by default - as we
don't know if the free space in VG is meant to be used for thin-pool or there
is some other plan admin might have...
More information about the linux-lvm