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

[Xen]

Zdenek Kabelac schreef op 11-09-2017 15:11:

> Thin-provisioning is - about 'postponing'  available space to be
> delivered in time

That is just one use case.

Many more people probably use it for other use case.

Which is fixed storage space and thin provisioning of available storage.

> You order some work which cost $100.
> You have just $30, but you know, you will have $90 next week -
> so the work can start....

I know the typical use case that you advocate yes.

> But it seems some users know it will cost $100, but they still think
> the work could be done with $10 and it's will 'just' work the same....

No that's not what people want.

People want efficient usage of data without BTRFS, that's all.

>> File system level failure can also not be critical because of using 
>> non-critical volume because LVM might fail even though filesystem does 
>> not fail or applications.
> 
> So my Laptop machine has 32G RAM - so you can have 60% of dirty-pages
> those may raise pretty major 'provisioning' storm....

Yes but still system does not need to crash, right.

>> Block level layer failure is much more serious, and can prevent system 
>> from recovering when it otherwise could.
> 
> Yep - the idea is - when thin-pool gets full - it will stop working,
> but you can't rely on 'usable' system when this happens....
> 
> Of course - it differs on case by case - if you run your /rootvolume
> out of such overfilled thin-pool - you have much bigger set of problems
> compared with user which has just some mount  data volume - so
> the rest of system is sitting on some 'fully provisioned' volume....

Yes.

> But we are talking about generic case here no on some individual 
> sub-cases
> where some limitation might give you the chance to rescue better...

But no one in his right mind currently runs /rootvolume out of thin pool 
and in pretty much all cases probably it is only used for data or for 
example of hosting virtual hosts/containers/virtualized 
environments/guests.

So Data use for thin volume is pretty much intended/common/standard use 
case.

Now maybe amount of people that will be able to have running system 
after data volumes overprovision/fill up/crash is limited.

However, from both a theoretical and practical standpoint being able to 
just shut down whatever services use those data volumes -- which is only 
possible if base system is still running -- makes for far easier 
recovery than anything else, because how are you going to boot system 
reliably without using any of those data volumes? You need rescue mode 
etc.

So I would say it is the general use case where LVM thin is used for 
data, or otherwise it is the "special" use case used by 90% of people...


In any case it wouldn't hurt anyone who didn't fall into that "special 
use case" scenario, it would benefit everyone.

Unless you are speaking perhaps about unmitigatable performance 
considerations.

Then it becomes indeed a tradeoff but you are the better judge of that.

> Again - it's admin's  gambling here - if he let the system 
> overprovisiong
> and doesn't have 'backup' plan -  you can't blame here  lvm2.....

He might have system backups.

He might be able to recover his system if his system is still allowed to 
be logged into.

That should be enough backup plan for most people who do not have 
expandable storage.

So maybe this is not main use case for LVM2, but it is still common use 
case that people keep asking about. So there is a demand for this.

Normal data volumes filling up is pretty much same situation.

Same user will not have backup plan in case volumes fill up.

Thin provisioning does not make that worse, normally.

That's where we start out from.

Thin provisioning with overprosisioning and expandable storage does 
improve that thing for those people, that want to have larger 
filesystems to cater to growth.

But people using slightly larger filesystems only for data space sharing 
between volumes...

Are trying to get a bit more flexibility (for example for moving data 
from partition to partition).

So for example I have 50GB VPS with Thin for data volumes.

If I want to reorganize my data across volumes I only have to ensure 
enough space in thin pool, or move in smaller parts so there is enough 
space for that.

Then I run fstrim and then everything is alright again.

This is benefit of me for thin pool.

It just makes moving data around a bit (a lot) easier.

So I first check thin space and then do operation.

So the only time when I near the "full" mark is when I do these 
operations.

My system is not data intensive (with just 50GB) and does not run quick 
risk of filling up -- but it could happen.

So that's all.

Regards.