Fwd: [wplug] Re: NFS Availability Issues -- why I should just help off-list ...

Bryan J. Smith thebs413 at yahoo.com
Wed Sep 12 21:35:52 EDT 2007


Brandon Poyner <bpoyner at gmail.com> wrote:
> That's really the wrong conclusion.  I specifically said I'm not a
> huge fan of NFS.

Then what do you use?  Or more relevant to the thread, what do you
see as a solution here?

> Costs really matter in some people's projects.
> I wasn't specifically addressing anything you said about costs.
> To quote the original poster:   "It wouldn't be out of the
> question to buy a second server to act as a hot spare at another 
> location, but it wouldn't be cheap or easy."

My apologies then.

> Not everybody is trying to run a ERP system

But where would a fail-over NFS -- or a fail-over network filesystem
in general -- have anything to do with ERP?

If you're not seeing a theme, and I don't mean to do this in spite of
anyone, but I'm just trying to keep any analogies inside of the
details of a high-availability, network filesystem solution.  Or at
least one that addresses home directories -- be they distributed,
replicated, cached, etc...

> and not everybody has the money to buy a SAN for their tiny
project.  

But that's the _only_ way you get _compatibility_ with what he needs.

> You sometimes have to find alternatives that work for your project
> that are within budget.

But those "alternatives" must be _compatible_.  If they don't have a
very required feature, it is _not_ an option.

> Nearly unlimited money could buy you five 9s .. I don't
> think the OP is in that position.

If you re-read my post, I was telling him it was _not_ worth such.

At the same time, if you _are_ going to have NFS fail-over for home
directories -- _not_ web servers or read-only or data served via a
stateless protocol -- but home directories, then it's hard to avoid
it.

> I'm not disagreeing that NFS over DRBD _could_ break on you,

It _will_.  ;)

Every single link and other commentary you posted was for supporting
multiple _web_ servers (or other, stateless Internet protocols) from
the same data pool.

> I have no direct experience with that.

Yes, we've been through that, and I didn't want to "focus" on that as
a result.  I've been criticized for doing that to people in the past,
even when they "corrected" me by offering an "alternative" they've
never used.  So I was hopeful you'd leave that be so I didn't have to
"focus" on it further.

> For what it's worth NFS isn't appropriate for many things
> (usenet server anyone?).

Sigh ...

Apparently you didn't catch the "97%" comment I made.  I've found
that 97% of Linux consultants focus on the web space.  As such, they
have their experiences with such services in that space.

Now that's not to say I haven't been running DNS, NNTP, SMTP and
other services myself since the '80s.  It's just that by the
mid-'90s, I got the hell out as Linux made it commodity and I was
"dime-a-dozen consultant."  ;)

As such, since the mid-'90s, I really try to limit what I say or how
I try to help people on such things as Apache.  Why?  Because I'm
wholly ignorant of what common ISP and other solution providers run
into.  I don't like to send someone with a _production_
system/network down the path of a solution unless I've already staked
my reputation on it.

Unfortunately, the 97% seem to continually push forth they are also
"experts" on network filesystems and non-web/simple IP protocol
systems that are commonly used for I/O bound services, especially
when it comes to concurrent file access and other details.

Again, and I'm sure you're sick of hearing it now, fail-over NFS for
web server data (especially read-only) introduces absolutely none of
the issues that you will run into for home directories and other,
write -- let alone concurrently written to -- user data.  Directories
are "always open" and various operations are "persistently locked"
and other things when you have home directories.  All the difference!

That's why things will most _absolutely_ "break."  That's why these
links and HOWTOs and other commentary you posted focus on web
services, and talk about what you can_not_ do with them.  Things that
KDE, GNOME, XFCE or even basic X operations do, let alone just a
login shell.  ;)

> All I know is that DRBD + NFS works for some people.

And I told you how it does, for "some people" doing "web services." 
That's _not_ what he's doing.  ;)

> If the original poster was looking for a "never fail" solution I
> would think he would have mentioned that.

No, you're still missing the point.

The original poster has home directories.  This solution does _not_
work for that.  I don't know how much _stronger_ I can say that.  I
don't say this because "I want to be right."

I say this because I've seen this happen over and over and over
again.  Someone recommends something they don't use, let alone does
it well outside the context of their own experience, let alone
outside the context of the original poster's application.

And then people lose sleep.  They lose their reputation.  And make no
mistake, I've even seen someone else lose their job over a LUG
recommended solution.  Luckily I was able to "deal that guy back in"
after I got them back up'n running, and explained what I call
"Linux's 97% problem" to his employer.  ;)

> Once again, the cost comments weren't directed at you.  It's
> directed at the OP.   Sorry if you mistook a general comment
> about costs as a slam or something.

Well I apologies for reading too much into it.  At the same time, I'm
trying to say you have to consider ...
- Context of the question
- A solution that addresses the question (under that context)
- Involves a solution you use (under that same context)
- A solution that actually (under that same context)

> I'm fairly sure I covered 1, 2, and 3 .. and 4 anecdotally.

Actually, you violated #1 off-the-bat, which followed by #2.  But
even that isn't bad, as long as you "qualify" it as, "I used this for
this context (e.g., web), but I haven't used it for your context
(e.g., home directories)."  You didn't do that.

But even that is excusable.  After all, all you were trying to do was
help.  I can't really lambast that.

What I had a problem with was really #3 and, as a result, #4.  You've
never even used it under your own context, much less his.  And even
that wasn't really enough to "get on you about."

What finally "did it" for me is when you started marginalizing what I
said.  Without a single of the 1-4, you marginalized some of what I
said.  Make no mistake, you're not the first person to do this to me.
 And make no mistake, the reason I have a problem with that has
_nothing_ to do with ego or standing.

It has to do with seeing someone go right in and screw up a
_production_ network.  I have several examples.  I even have examples
were I was berated by someone's answer (you didn't do this, not
saying you did), and then the person finally had to admit they had
never done it before, nor even realized all that was involved. 
_After_ someone royally dorked up their network as a result.

In one other case, it was that one "guy with 3 kids."  I bailed him
out.  It was one of the last times I did after what would happen
shortly afterwards.  Long story.

> Like I said, not a big fan of NFS.

So, again, I ask ... _what_ "network filesystem" do you use for
remote home directories then?  What about general, local subnet file
sharing?  At a "mount" level?

Or what strategies do you use to _avoid_ that?  Local home
directories with rsync?  Selective remote network filesystems as
little as possible?  What?

You can say "I'm not a fan of NFS" and that you don't have anything
against network filesystems, but to date, you have offered _nothing_
that helps him.  And even that aside, and I don't mean to harp on
this, but you're showing me you have _no_ familiarity with the issues
involved here.

Every single one of your analogies and examples has been web or
simple Internet protocol related, 0 related to home directories and
management.  At most, I have "thin client/terminal servers" to go on
in a brief statement by you.

> Sometimes that's due to sloppiness, sure.  Other times it's due to
> not understanding how large a project will become (perhaps more
> sloppiness).  Linux is full of ways to shoot yourself in the foot
> and often without a support agreement.   If the good solutions were
> cheap, everybody would be using them.

But solutions that _never_ work are _never_ feasible.  ;)

There's nothing more dangerous than a Linux consultant (or any
consultant for that matter) who doesn't know the application or
context they are getting into.  Worse yet is the one that recommends
a solution they have never used under a context, much less never used
under _any_ context, one that utterly _breaks_ under the context.

That's what we have here.


-- 
Bryan J. Smith   Professional, Technical Annoyance
b.j.smith at ieee.org    http://thebs413.blogspot.com
--------------------------------------------------
     Fission Power:  An Inconvenient Solution


More information about the wplug mailing list