Re: [linux-lvm] Snapshot behavior on classic LVM vs ThinLVM

[Xen <list@xenhideout.nl>]

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