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

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 27.2.2018 v 19:39 Xen napsal(a):
> Zdenek Kabelac schreef op 24-04-2017 23:59:
> 
>>>> I'm just currious -� what the you think will happen when you have
>>>> root_LV as thin LV and thin pool runs out of space - so 'root_LV'
>>>> is replaced with 'error' target.
>>>
>>> Why do you suppose Root LV is on thin?
>>>
>>> Why not just stick to the common scenario when thin is used for extra 
>>> volumes or data?
>>>
>>> I mean to say that you are raising an exceptional situation as an argument 
>>> against something that I would consider quite common, which doesn't quite 
>>> work that way: you can't prove that most people would not want something by 
>>> raising something most people wouldn't use.
>>>
>>> I mean to say let's just look at the most common denominator here.
>>>
>>> Root LV on thin is not that.
>>
>> Well then you might be surprised - there are user using exactly this.
> 
> I am sorry, this is a long time ago.
> 
> I was concerned with thin full behaviour and I guess I was concerned with 
> being able to limit thin snapshot sizes.
> 
> I said that application failure was acceptable, but system failure not.

Hi

I'll probably repeat my self again, but thin provision can't be responsible 
for all kernel failures. There is no way DM team can fix all the related paths 
on this road.

If you don't plan to help resolving those issue - there is not point in 
complaining over and over again - we are already well aware of this issues...

Admin needs to be aware of 'pros & cons'  and have to use thin technology at 
the right place for the right task.

If the admin can't stand failing system, he can't use thin-p.

Overprovisioning on DEVICE level simply IS NOT equivalent to full filesystem 
like you would like to see all the time here and you've been already many 
times explained that filesystems are simply not there ready - fixes are on 
going but it will take its time and it's really pointless to exercise this on 
2-3 year old kernels...

Thin provisioning has it's use case and it expects admin is well aware of 
possible problems.

If you are aiming for a magic box working always right - stay away from thin-p 
- the best advice....

> Even if root is on thin and you are using it for snapshotting, it would be 
> extremely unwise to overprovision such a thing or to depend on "additional 
> space" being added by the admin; root filesystems are not meant to be expandable.

Do NOT take thin snapshot of your root filesystem so you will avoid thin-pool 
overprovisioning problem.

> True enough, but if you risk filling your pool because you don't have full 
> room for a full snapshot, that would be extremely unwise. I'm also not sure 
> write performance for a single snapshot is very much different between thin 
> and non-thin?

Rule #1:

Thin-pool was never targeted for 'regular' usage of full thin-pool.
Full thin-pool is serious ERROR condition with bad/ill effects on systems.
Thin-pool was designed to 'delay/postpone' real space usage - aka you can use 
more 'virtual' space with the promise you deliver real storage later.

So if you have different goals - like having some kind of full equivalency 
logic to full filesystem - you need to write different target....


> I simply cannot reconcile an attitude that thin-full-risk is acceptable and 
> the admin's job while at the same time advocating it for root filesystems.

Do NOT use thin-provinioning - as it's not meeting your requirements.

> Now most of this thread I was under the impression that "SYSTEM HANGS" where 
> the norm because that's the only thing I ever experienced (kernel 3.x and 
> kernel 4.4 back then), however you said that this was fixed in later kernels.

Big news -  we are at ~4.16 kernel upstream - so noone is really taking much 
care about 4.4 troubles here - sorry about that....

Speaking of 4.4 - I'd generally advice to jump to higher versions of kernel 
ASAP - since  4.4 has some known bad behavior in the case thin-pool 'metadata' 
get overfilled.


>> lvm2 is cooking some better boot support atm....
> 
> Grub-probe couldn't find the root volume so I had to maintain my own grub.cfg.

There is on going 'BOOM' project - check it out please....


>> There should not be any hanging..
> 
> Right well Debian Jessie and Ubuntu Xenial just experienced that.

There is not much point in commenting support for some old distros other then 
you really should try harder with your distro maintainers....

>>> That's irrelevant; if the thin pool is full you need to mitigate it, 
>>> rebooting won't help with that.
>>
>> well it's really admins task to solve the problem after panic call.
>> (adding new space).
> 
> That's a lot easier if your root filesystem doesn't lock up.

- this is not really a fault of dm thin-provisioning kernel part.
- on going fixes to file systems are being pushed upstream (for years).
- fixes will not appear in years old kernels as such patches are usually 
invasive so unless you use pay someone to do the backporting job the easiest 
way forward is to user newer improved kernel..

> When my root snapshot fills up and gets dropped, I lose my undo history, but 
> at least my root filesystem won't lock up.

lvm2 fully support these snapshots as well as thin-snapshots.
Admin has to choose 'the best fit'

ATM  thin-pool can't deliver equivalent logic - just like old-snaps can't 
deliver thin-pool logic.

> However, I don't have the space for a full copy of every filesystem, so if I 
> snapshot, I will automatically overprovision.

Back to rule #1 - thin-p is about 'delaying' deliverance of real space.
If you already have plan to never deliver promised space - you need to live 
with consequences....


> My snapshots are indeed meant for backups (of data volumes) ---- not for 
> rollback ----- and for rollback ----- but only for the root filesystem.

There is more fundamental problem here:

!SNAPSHOTS ARE NOT BACKUPS!

This is the key problem with your thinking here (unfortunately you are not 
'alone' with this thinking)


> With sufficient monitoring I guess that is not much of an issue.

We do provide quite good 'scripting' support for this case - but again if
the system can't crash - you can't use thin-pool for your root LV or you can't 
use over-provisioning.


> My problem was system hangs, but my question was about limiting snapshot size 
> on thin.

Well your problem primarily is usage of too old system....

Sorry to say this - but if you insist to stick with old system - ask your 
distro maintainers to do all the backporting work for you - this is nothing 
lvm2 can help with...


Regards

Zdenek