Zdenek Kabelac schreef op 28-02-2018 22:43:
It still depends - there is always some sort of 'race' - unless you
are willing to 'give-up' too early to be always sure, considering
there are technologies that may write many GB/s...
That's why I think it is only possible for snapshots.
You can use rootfs with thinp - it's very fast for testing i.e.
upgrades
and quickly revert back - just there should be enough free space.
That's also possible with non-thin.
Snapshot are using space - with hope that if you will 'really' need
that space
you either add this space to you system - or you drop snapshots.
And I was saying back then that it would be quite easy to have a script
that would drop bigger snapshots first (of larger volumes) given that
those are most likely less important and more likely to prevent thin
pool fillup, and you can save more smaller snapshots this way.
So basically I mean this gives your snapshots a "quotum" that I was
asking about.
Lol now I remember.
You could easily give (by script) every snapshot a quotum of 20% of full
volume size, then when 90% thin target is reached, you start dropping
volumes with the largest quotum first, or something.
Idk, something more meaningful than that, but you get the idea.
You can calculate the "own" blocks of the snapshot and when the pool is
full you check for snapshots that have surpassed their quotum, and the
ones that are past their quotas in the largest numbers you drop first.
But as said - with today 'rush' of development and load of updates -
user do want to try 'new disto upgrade' - if it works - all is fine -
if it doesn't let's have a quick road back - so using thin volume for
rootfs is pretty wanted case.
But again, regular snapshot of sufficient size does the same thing, you
just have to allocate for it in advance, but for root this is not really
a problem.
Then no more issue with thin-full problem.
I agree, less convenient, and a slight bit slower, but not by much for
this special use case.
There are also some on going ideas/projects - one of them was to have
thinLVs with priority to be always fully provisioned - so such thinLV
could never be the one to have unprovisioned chunks....
That's what ZFS does... ;-).
Other was a better integration of filesystem with 'provisioned'
volumes.
That's what I was talking about back then...............
_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
