I did not rewrite this entire message, please excuse the parts where I
am a little more "on the attack".
Zdenek Kabelac schreef op 28-02-2018 10:26:
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.
Are you saying there are kernel bugs presently?
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...
I'm not aware of any issues, what are they?
I was responding here to an earlier thread I couldn't respond to back
then, the topic was whether it was possible to limit thin snapshot
sizes, you said it wasn't, I was just recapping this thread.
If the admin can't stand failing system, he can't use thin-p.
That just sounds like a blanket excuse for any kind of failure.
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...
Pardon me, but your position has typically been that it is fundamentally
impossible, not that "we're not there yet".
My questions have always been about fundamental possibilities, to which
you always answer in the negative.
If something is fundamentally impossible, don't be surprised if you then
don't get any help in getting there: you always close off all paths
leading towards it.
You shut off any interest, any discussion, and any development interest
in paths that a long time later, you then say "we're working on it"
whereas before you always said "it's impossible".
This happened before where first you say "It's not a problem, it's admin
error" and then a year later you say "Oh yeah, it's fixed now".
Which is it?
My interest has always been, at least philosophically, or concerning
principle abilities, in development and design, but you shut it off
saying it's impossible.
Now you complain you are not getting any help.
Thin provisioning has it's use case and it expects admin is well aware
of possible problems.
That's a blanket statement once more that says nothing about actual
possibilities or impossibilities.
If you are aiming for a magic box working always right - stay away
from thin-p - the best advice....
Another blanket statement excusing any and all mistakes or errors or
failures the system could ever have.
Do NOT take thin snapshot of your root filesystem so you will avoid
thin-pool overprovisioning problem.
Zdenek, could you please make up your mind?
You brought up thin snapshotting as a reason for putting root on thin,
as a way of saying that thin failure would lead to system failure and
not just application failure,
whereas I maintained that application failure was acceptable.
I tried to make the distinction between application level failure (due
to filesystem errors) and system instability caused by thin.
You then tried to make those equivalent by saying that you can also put
root on thin, in which case application failure becomes system failure.
I never wanted root on thin, so don't tell me not to snapshot it, that
was your idea.
Rule #1:
Thin-pool was never targeted for 'regular' usage of full thin-pool.
All you are asked is to design for error conditions.
You want only to take care of the special use case where nothing bad
happens.
Why not just take care of the general use case where bad things can
happen?
You know, real life?
In any development process you first don't take care of all error
conditions, you just can't be bothered with them yet. Eventually, you
do.
It seems you are trying to avoid having to deal with the glaring error
conditions that have always existed, but you are trying to avoid having
to take any responsibility for it by saying that it was not part of the
design.
To make this more clear Zdenek, your implementation does not cater to
the general use case of thin provisioning, but only to the special use
case where full thin pools never happen.
That's a glaring omission in any design. You can go on and on on how
thin-p was not "targetted" at that "use case", but that's like saying
you built a car engine that was not "targetted" at "running out of
fuel".
Then when the engine breaks down you say it's the user's fault.
Maybe retarget your design?
Running out of fuel is not a use case.
It's a failure condition that you have to design for.
Full thin-pool is serious ERROR condition with bad/ill effects on
systems.
Yes and your job as a systems designer is to design for those error
conditions and make sure they are handled gracefully.
You just default on your responsibility there.
The reason you brought up root on thin was to elevate application
failure to the level of system failure so as to make them equivalent and
then to say that you can't do anything about system failure.
This is a false analogy, we only care about application failure in the
general use case of stuff that is allowed to happen, and we distinguish
system failure which is not allowed to happen.
Yes Zdenek, system failure is your responsibility as the designer, it's
not the admin's job except when he has a car that breaks down when the
fuel runs out.
But that, clearly, would be seen as a failure on behalf of the one
designing the engine.
You are responding so defensively when I have barely said anything that
it is clear you feel extremely guilty about this.
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.
That doesn't cover the full spectrum of what we consider to be "thin
provisioning".
You only designed for a very special use case in which the fuel never
runs out.
The aeroplane that doesn't need landing gear because it was designed to
never run out of fuel.
In the kingdom of birds, only swallows do that. Most other birds are
designed for landing and taking off too.
You built a system that only works if certain conditions are met.
I'm just saying you could expand your design and cover the error
conditions as well.
So yes: I hear you, you didn't design for the error condition.
That's all I've been saying.
So if you have different goals - like having some kind of full
equivalency logic to full filesystem - you need to write different
target....
Maybe I could but I still question why it was not designed into thin-p,
and I also doubt that it couldn't be redesigned into it.
I mean I doubt that it would require a huge rewrite, I think that if I
were to do that thing, I could start off with thin-p just fine.
Certainly, interesting, and a worthy goal.
There are a billion fun projects I would like to take on, but generally
I am just inquiring, sometimes I am angry about stuff not working,
but when I talk about "could this be possible?" you can assume I am
talking from a development perspective, and you don't have to constantly
only defend the thing currently not existing.
Sometimes I am just asking about possibilities.
"Yes, it doesn't exist, and it would require that and that and that"
would be a sufficient answer.
I don't always need to hear all of the excuses as to why it isn't so,
sometimes I just wonder how it could be done.
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.
It was your suggestion to use thin for root as a way of artificially
increasing those requirements and then saying that they can't be met.
Big news - we are at ~4.16 kernel upstream - so noone is really
taking much care about 4.4 troubles here - sorry about that....
I said back then.
You don't really listen, do you...
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.
I never said that I was using 4.4, if you took care to read you would
see that I was speaking about the past.
Xenial is at 4.13 right now.
There is on going 'BOOM' project - check it out please....
Okay...
There is not much point in commenting support for some old distros
other then you really should try harder with your distro
maintainers....
I was just explaining why I was experiencing hangs and you didn't know
what I was talking about, causing some slight confusion in our threads.
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.
I was saying, Zdenek, that your suggestion to use root on thin was
rather unwise.
I don't know what you're defending against, I never said anything other
than that.
- 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..
I understand that you are mixing up my system hangs with the above
problems you would have by using root on full thin pool, I have already
accepted that the system hangs are fixed in later kernels.
ATM thin-pool can't deliver equivalent logic - just like old-snaps
can't deliver thin-pool logic.
Sure, but my question was never about "ATM".
I asked about potential, not status quo.
Please, if you keep responding to development inquiries with status quo
answers, you will never find any help in getting there.
The "what is" and the "what is to be" don't have to be the same, but you
are always responding defensively as to the "what is", not understanding
the questions.
Those system hangs, sure, status quo. Those snapshots? Development
interest.
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....
Like I said, I was just INQUIRING about the possibility of limiting the
size of a thin snapshot.
The fact that you respond so defensively with respect to thin pools
overflowing, means you feel and are guilty about not taking care of that
situation.
I was inquiring about a way to prevent thin pool overflow.
If you then suggest that the only valid use case is to have some
auto-expanding pool, then either you are not content with just giving
the answer to that question, or you feel it's your fault that something
isn't possible and you try to avoid that by putting the blame on the
user for "using it in a wrong way".
I asked a technical question. You respond like a guy who is asked why he
didn't clean the bathroom.
According to schedule.
Easy now, I just asked whether it was possible or not.
I didn't ask you to explain why it hasn't been done.
Or where to put the blame for that.
I would say you feel rather guilty and to every insinuation that there
is a missing feature you respond with great noise as to why the feature
isn't actually missing.
So if I say "Is this possible?" you respond with "YOU ARE USING IT THE
WRONG WAY" as if to feel rather uneasy to say that something isn't
possible.
Which again, leads, of course, to bad design.
Your uneasiness Zdenek is the biggest signpost here.
Sorry to be so liberal here.
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!
Can you please stop screaming?
Do I have to spell out that I use the snapshot to make the backup and
then discard the snapshot?
This is the key problem with your thinking here (unfortunately you are
not 'alone' with this thinking)
Yeah, maybe you shouldn't jump to conclusions and learn to read better.
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....
I said "was", learn to read, Zdenek.
Sorry to say this - but if you insist to stick with old system
Where did I say that? I said that back then, I had an 4.4 system that
experienced these issues.
- ask
your distro maintainers to do all the backporting work for you - this
is nothing lvm2 can help with...
I explained to you that our confusion back then was due to my using the
then-current release of Ubuntu Xenial which had these problems.
I was just responding to an old thread with these conclusions:
1) Our confusion with respect to those "system hangs" was due to the
fact that you didn't know what I was talking about, thus I thought you
were excusing them, when you weren't.
2) My only inquiry had been about preventing snapshot overflow.
_______________________________________________
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/
