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

[Zdenek Kabelac]

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 
problem....

> Being able to set a maximum snapshot size before it gets dropped could be very 
> nice.

You can't do that IN KERNEL.

The only tool which is able to calculate real occupancy - is user-space 
thin_ls tool.

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 
data structures.

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...


Regards

Zdenek