Brassow Jonathan schreef op 15-09-2017 4:06:
There are many solutions that could work - unique to every workload
and different user. It is really hard for us to advocate for one of
these unique solutions that may work for a particular user, because it
may work very badly for the next well-intentioned googler.
Well, thank you.
Of course in the split between saying "it is the administrator's job
that everyone works well" and at the same time saying that those
administrators can be "googlers".
There's a big gap between that. I think that many who do employ thinp
will be at least a bit more serious about it, but perhaps not as serious
that they can devote all the resources to developing all of the
mitigating measures that anyone could want.
So I think the common truth lies more in the middle: they are not
googlers who implement the first random article they find without
thinking about it, and they are not professional people in full time
employment doing this thing.
So because of that fact that most administrators interested in thin like
myself will have read LVM manpages a great deal already on their own
systems...
And any common default targets for "thin_command" could also be well
documented and explained, and pros and cons layed out.
The only thing we are talking about today is reserving space due to some
threshold.
And performing an action when that reservation is threatened.
So this is the common need here.
This need is going to be the same for everyone that uses any scheme that
could be offered.
Then the question becomes: are interventions also as common?
Well there are really only a few available:
a) turning into error volume as per the bug
b) fsfreezing
c) merely reporting
d) (I am not sure if "lvremove" should really be seriously considered).
At this point you have basically exhausted any default options you may
have that are "general". No one actually needs more than that.
What becomes interesting now is the logic underpinning these decisions.
This logic needs some time to write and this is the thing that
administrators will put off.
So they will live with not having any intelligence in automatic response
and will just live with the risk of a volume filling up without having
written the logic that could activate the above measures.
That's the problem.
So what I am advocating for -- I am not disregarding Mr. Zdenek's bug
;-), [1], In fact I think this "lverror" would be very welcome
(paraphrasing here) even though personally I would want to employ a
filesystem mechanic if I am doing this using a userland too anyway!!!
But sure, why not.
I think that is complementary to and orthogonal to the issue of where
the logic is coming from, and that the logic also requires a lot of
resources to write.
So even though you could probably hack it together in some 15 minutes,
and then you need testing etc...
I think it would just be a lot more pleasant if this logic framework
already existed, was tried and tested, did the job correctly, and can
easily be employed by anyone else.
So I mean to say that currently we are only talking about space
reservation.
You can only do this in a number of ways:
- % of total volume size.
- fixed amount configured per volume
And that's basically it.
The former merely requires each volume to be 'flagged' as 'critical' as
suggested.
The latter requires some number to be defined and then flagging is
unnecessary.
The script would ensure that:
- not ALL thin volumes are 'critical'.
- as long as a single volume is non-critical, the operation can continue
- all critical volumes are aggregated in required free space
- the check is done against currently available free space
- the action on the non-critical-volumes is performed if necessary.
That's it. Anyone could use this.
The "Big vs. Small" model is a little bit more involved and requires a
little bit more logic, and I would not mind writing it, but it follows
along the same lines.
*I* say that in this department, *only* these two things are needed.
+ potentially the lverror thing.
So I don't really see this wildgrowth of different ideas.
So personally I would like the "set manual size" more than the "use
percentage" in the above. I would not want to flag volumes as critical,
I would just want to set their reserved space.
I would prefer if I could set this in the LVM volumes themselves, rather
than in the script.
If the script used a percentage, I would want to be able to configure
the percentage outside the script as well.
I would want the script to do the heavy lifting of knowing how to
extract these values from the LVM volumes, and some information on how
to put them there.
(Using tags and all of that is not all that common knowledge I think).
Basically, I want the script to know how to set and retrieve properties
from the LVM volumes.
Then I want it to be easy to see the reserved space (potentially)
(although this can conflict with not being a really integrated feature)
and perhaps to set and change it...
So I think that what is required is really only minimal...
But that doesn't mean it is unnecessary.
We’ve tried to strike a balance of doing the things that are knowably
correct and getting 99% of the problems solved, and making the user
aware of the remaining problems (like 100% full thin-provisioning)
while providing them the tools (like the ‘thin_command’ setting) so
they can solve the remaining case in the way that is best for them.
I am really happy to learn about these considerations.
I hope that we can see as the result of this today the inclusion of the
script you mentioned in the previous email.
Something that hopefully would use values tagged into volumes, and a
script that would need no modification by the user.
Something that would e.g. be called with the name of the thin pool as
first parameter (pardon my ignorance) and would take care of all the
rest by retrieving values tagged onto volumes.
( I mean that's what I would write, but if I were to write it probably
no one else would ever use it, so .... (He says with a small voice) ).
And personally I would prefer this script to use "fsfreeze" as you
mentioned (I was even not all that aware of this command...) rather than
changing to an error target.
But who knows.
I am not saying it's a bad thing.
Seems risky though.
So honestly I just completely second the script you proposed, mr.
Jonathan.
;-).
While I still don't know why any in-kernel thing is impossible, seeing
that Zdenek-san mentioned overall block availability to be known, and
that you only need overall block availability + some configured values
to impose any sanctions on non-critical volumes.....
I would hardly feel a need for such a measure if the script mentioned
and perhaps the other idea that I like so much of "big vs small" would
be readily available.
I really have no other wishes than that personally.
It's that simple.
Space reservation and big to small protection.
Those are the only things I want.
Now all that's left to do is upgrade my LVM version ;-).
(Hate messing with a Debian install ;-)).
And I feel almost like writing it myself after having talked about it
for so long anyway...
(But that's what happens when you develop ideas).
We probably won’t be able to provide any highly refined scripts that
users can just plug in for the behavior they want, since they are
often so highly specific to each customer. However, I think it will
be useful to try to create better tools so that users can more easily
get the behavior they want. We want to travel as much distance toward
the user as possible and make things as usable as we can for them.
From this discussion, we have uncovered a handful of useful ideas
(e.g. this bug that Zdenek filed:
https://bugzilla.redhat.com/show_bug.cgi?id=1491609) that will make
more robust scripts possible. We are also enhancing our reporting
tools so users can better sort through LVM information and take
action. Again, this is in direct response to the feedback we’ve
gotten here.
Well that's very good. It took me a long time to sort through the
information without the thinls command.
Indeed, if such data is readily available it makes the burden of writing
the script yourself much less as well.
Still I would still vouch for the inclusion of the 2 scripts mentioned:
- space reservation
- big vs. small
And I don't mind writing the second one myself, or at least an example
of it.
Regards.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1491609
_______________________________________________
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/
