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
_______________________________________________
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/
