matthew patton schreef op 03-05-2016 15:01:
Ceph?!? yeah I don't think so.
Mark's argument was nothing about comparing feature sets or something at
this point. So I don't know what you are responding to. You respond like
a bitten bee.
Read again. Mark Mielke described actual present-day positions. He
described what he thinks is how LVM is positioning itself in conjunction
with and with regards to other solutions in industry. He described that
to his mind the bigger remote storage solutions do not or would not
easily or readily start using LVM for those purposes, while the smaller
scale or more localized systems would.
He described a layering solution, that you seem to be allergic to. He
described a modularized system where thin is being used both at the
remote backend (using a different technology) and at the local end
(using LVM) for different purposes but achieving much of the same
results.
He described how he considered the availability of the remote pool a
responsibility for that remote supplier (and paying good money for it)
while having different uses cases for LVM thin himself or themselves.
And I did think he made a very good case for this. I absolutely believe
his use case is the most dominant and important one for LVM. LVM is for
local systems.
In this case it is a local system running storage on a remote backend.
Yet the local system has different requirements and uses LVM thin for a
different purpose.
And this purpose falls along the lines of having cheap and freely
available snapshots.
And he still feels and believes, apparently, that using the LVM admin
tools for ensuring the stability of his systems might not be the most
attractive and functional thing to do.
You may not agree with that but it is what he believes and feels. It is
a real life data point, if you care about that.
Sometimes people's opinions actually simply just inform you of the
world. It is information. It is not something to fight or disagree with,
it is something to take note of.
The better you are able to respond to these data points, the better you
are aware of the system you are dealing with. That could be real people
paying or not paying you money.
However if you are going to fight every opinion that disagrees with you,
you will never get to the point of actually realizing that they are just
opinions and they are a wealth of information if you'd make use of it.
And that is not a devious thing to do if you're thinking that. It is
being aware. Nothing more, nothing less.
And we are talking about awareness here. Not surprising then that the
people most vehemently opposing this also seem to be the people least
aware of the fact that real people with real uses cases might find the
current situation not practical.
Mr. Zdenek can say all he wants that the current situation is very
practical.
If that is not a data point but an opinion (not of someone experiencing
it, but someone who wants certain people to experience certain things)
then we must listen to actual data points and not what he wants.
Mr. Zdenek (I haven't responded to him here now) also responds like a
bitten bee to simple allusions that Red Hat might be thinking this or
that.
Not just stung by a bee. A bee getting stung ;-).
I mean come on people. You have nothing to lose. Either it is a good
idea or it isn't. If it gets support, maybe someone will implement it
and deliver proof of concept. But if you go about shooting it down the
moment it rears its ugly (or beautiful) head you also ensure that that
developer time is not going to be spend on it even if it were an asset
to you.
Someone discussing a need might not always be that person that in the
end is not going to do anything himself.
You are trying to avoid work but in doing so you avoid work being done
for you as well.
It's give or take, it's plus plus.
Don't kill other people's ideas and maybe they start doing work for you
too.
Oh yeah. Sorry if I'm being judgmental or belligerent (or pedantic):
The great irony and tragedy of the Linux world is this:
Someone comes with a great idea that he/she believes in and wants to
work on.
They shoot it down.
Next they complain why there are so very few volunteers.
They can ban someone on a mailing list one instant and out loud wonder
how they can attract more interest to their system, the next.
Not unrelated.
sure, but that spells responsible sysadmin. Xen's post implied he
didn't want to be bothered to manage his block layer that magically
the FS' job was to work closely with the block layer to suss out when
it was safe to keep accepting writes. There's an answer to "works
closely with block layer" - it's spelled BTRFS and ZFS.
It is not my block layer. I'm not the fucking system admin.
I can only talk to the FS. Or that might very well be the case for my
purposes here.
It is pretty amazing that any attempt to separate responsibilities in
actuality is met with a rebuttal that insists one use a solution that
mingles everything.
In your ideal world then, everyone is forced to use BTRFS/ZFS because at
least these take the worries away from the software/application
designer.
And you ensure a beautiful world without LVM because it has no purpose.
As as software developer I cannot depend on your magical solution and
assertion that every admin out there is going to be this amazing person
that never makes a mistake.
Responsible usage has nothing to do with single vs multiple customers.
Though Xen broached the 'hosting' example and in the cut-rate hosting
business over-provisioning is rampant. It's not a problem unless the
syadmin drops the ball.
What if I want him to be able to drop the ball and still survive?
What about designing systems that are actually failsafe and resilient?
What about resilience?
What about goodness?
What about quality?
What about good stuff?
Why do you feed your admins bad stuff just so that they can shine and
consider themselves important?
So you're going to write and then backport "second guess the block
layer" code to all filesystems in common use and god knows how many
versions back? Of course not. Just try to get on the EXT developer
mailing list and ask them to write "block layer second-guessing code
(aka branch on device flag=thin)" because THINP will cause problems
for the FS when it runs out of extents. To which the obvious and
correct response will be "Don't use THINP if you're not prepared to
handle it's pre-requisites."
So you are basically suggesting a solution that you know will fail, but
still you recommend it.
That spells out "I don't know how to achieve my goals" like no other
thing.
But you still think people should follow your recommendations.
What you say is completely anemic to how the open source world works.
You do not ask people to do your work for you.
Why do you even insist on recommending that. And then when you (in your
imagination here) do ask those people to do it for you, they refuse. No
small wonder.
Still you consider that a good way to approach things. To depend on
someone else to do your work for you.
Really.
"Of course not. Just try to get on the EXT developer mailing list and
ask them to..."
Yes I am ridiculing you.
You were sincere in saying those words. You ridicule yourself.
Of course you would start designing patches and creating a workable
solution with yourself as the main leader or catalyst of that project.
There is not other way to do things in life. You should know that.
Then by all means go ahead and retrofit all known filesystems with the
extra logic. ALL of the filesystems were written with the
understanding that the block layer is telling the truth and that any
"white lie" was benign in so much that it would be made good and thus
could be assumed to be "truth" for practical purpose.
Maybe we should also retrofit all unknown filesystems and those that
might be designed on different planets. Yeah, that would be a good way
to approach things.
I really want to follow your recommendations here. If I do, I will have
good chances of achieving success.
_______________________________________________
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/
