[linux-lvm] Reserve space for specific thin logical volumes
zkabelac at redhat.com
Tue Sep 12 11:46:51 UTC 2017
Dne 11.9.2017 v 15:46 Xen napsal(a):
> 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.
What's wrong with BTRFS....
Either you want fs & block layer tied together - that the btrfs/zfs approach
or you want
layered approach with separate 'fs' and block layer (dm approach)
If you are advocating here to start mixing 'dm' with 'fs' layer, just
because you do not want to use 'btrfs' you'll probably not gain main traction
>>> 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.
We need to see EXACTLY which kind of crash do you mean.
If you are using some older kernel - then please upgrade first and
provide proper BZ case with reproducer.
BTW you can imagine an out-of-space thin-pool with thin volume and filesystem
as a FS, where some writes ends with 'write-error'.
If you think there is OS system which keeps running uninterrupted, while
number of writes ends with 'error' - show them :) - maybe we should stop
working on Linux and switch to that (supposedly much better) different OS....
>> 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.
You can have different pools and you can use rootfs with thins to easily test
i.e. system upgrades....
> 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.
Most thin-pool users are AWARE how to properly use it ;) lvm2 tries to
minimize (data-lost) impact for misused thin-pools - but we can't spend too
much effort there....
So what is important:
'commited' data (i.e. transaction database) are never lost
fsck after reboot should work.
If any of these 2 condition do not work - that's serious bug.
But if you advocate for continuing system use of out-of-space thin-pool - that
I'd probably recommend start sending patches... as an lvm2 developer I'm not
seeing this as best time investment but anyway...
> However, from both a theoretical and practical standpoint being able to just
> shut down whatever services use those data volumes -- which is only possible
Are you aware there is just one single page cache shared for all devices
in your system ?
> 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.
Again do you have use-case where you see a crash of data mounted volume
on overfilled thin-pool ?
On my system - I could easily umount such volume after all 'write' requests
are timeouted (eventually use thin-pool with --errorwhenfull y for instant
So please can you stop repeating overfilled thin-pool with thin LV data volume
kills/crashes machine - unless you open BZ and prove otherwise - you will
surely get 'fs' corruption but nothing like crashing OS can be observed on my
We are here really interested in upstream issues - not about missing bug fixes
backports into every distribution and its every released version....
> He might be able to recover his system if his system is still allowed to be
> logged into.
There is no problem with that as long as /rootfs has consistently working fs!
More information about the linux-lvm