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

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 21.9.2017 v 16:49 Xen napsal(a):
> 
> However you would need LVM2 to make sure that only origin volumes are marked 
> as critical.

'dmeventd' executed binary - which can be a simple bash script called at 
threshold level can be tuned to various naming logic.

So far there is no plan to enforce 'naming' or 'tagging' since from user base 
feedback we can see numerous ways how to deal with large volume naming 
strategies often made by external tools/databases -  so enforcing i.e. 
specific tag would require changes in larger systems - so when it's compared 
with rather simple tuning script of bash script...


> I actually think that if I knew how to do multithreading in the kernel, I 
> could have the solution in place in a day...
> 
> If I were in the position to do any such work to begin with... :(.
> 
> But you are correct that error target is almost the same thing.

It's the most 'safest'  - avoids any sort of further possibly damaging of 
filesystem.

Note - typical 'fs' may remount 'ro' at reasonable threshold time - the 
precise points depends on workload. If you have 'PB' arrays - surely leaving 
5% of free space is rather huge, if you work with GB on fast operation SSD - 
taking action at 70% might be better.

If anytime 'during' write  users hits 'full pool' - there is currently no 
other way then to stop using FS  - there are numerous way -

You can replace device with 'error'
You can replace device with 'delay' that splits reads to thin and writes to error

There is just not any way-back - FS should be checked  (i.e. full FS could be 
'restored' by deleting some files, but in the full thin-pool case  'FS' needs 
to get consistent first - so focusing on solving full-pool is like preparing 
for missed battle - focus should go into ensuring you not hit full pool and on 
the 'sad' occasion of 100% full pool - the worst case scenario is not all the 
bad - surely way better then 4 year old experience with old kernel and old 
lvm2....

>> What you would have to implement is to TAKE the space FROM them to
>> satisfy writing task to your 'active' volume and respect
>> prioritization...
> 
> Not necessary. Reserved space is a metric, not a real thing.
> 
> Reserved space by definition is a part of unallocated space.

How is this different from having VG with 1TB where you allocate for your 
thin-pool only i.e. 90% for thin-pool and you have 10% of free space for 
'extension' of thin-pool for your 'critical' moment.

I'm still not seeing any difference - except you would need to invest lot of 
energy into handling of this 'reserved' space inside kernel.

With actual versions of lvm2 you can handle these tasks at user-space and 
quite early before you reach 'real' out-of-space condition.

>> In other words - tuning 'thresholds' in userspace's 'bash' script will
>> give you very same effect as if you are focusing here on very complex
>> 'kernel' solution.
> 
> It's just not very complex.
> 
> You thought I wanted space consumption metric for all volumes including 
> snapshots and then invididual attribution of all consumed space.


Maybe you can try existing proposed solutions first and showing 'weak' points 
which are not solvable by it ?

We all agree we could not store 10G thin volume into 1G thin-pool - so there 
will be always the case of having  'full pool'.

Either you could handle reserves of 'early' remount-ro  or you keep some 
'spare' LV/space in VG you attach to thin-pool 'when' needed...
Having such 'great' level of free choice here is IMHO big advantage as it's 
always 'admin' to decide how to use available space in the best way -  instead 
of keeping 'reserves' somewhere hidden in kernel....

Regards

Zdenek