[wplug] Network filesystems and other,
desktop application considerations -- WAS: NFS Availability Issues
Bryan J. Smith
b.j.smith at ieee.org
Thu Sep 13 17:15:30 EDT 2007
Brandon Poyner <bpoyner at gmail.com> wrote:
> I don't know near enough details of the OP's problem, budget, and
> remaining time to implement to jump to a solution.
I wasn't asking that. To refresh your memory ...
[ And yes, this is beating a dead horse because I don't expect any
explanation in the end, which is abusing the list ... ]
Brandon wrote:
> and I'll say that I personally don't use DRBD + HA
> for any type of NFS services.
> In fact I'm not a huge fan of NFS partially because
> it's not 'designed for' high availability. I've
> been using DRBD for web, mail, smtp, lpd, etc without
> any type of file open/locking issues.
So at one point, I then stated ...
Bryan wrote:
> After reading your statements, its as if you don't
> ever see a need for network filesystems in general.
Which you responded ...
Brandon wrote:
> That's really the wrong conclusion. I specifically
> said I'm not a huge fan of NFS.
Which prompted my inquiry ...
Bryan asked:
> Then what do you use? Or more relevant to the thread,
> what do you see as a solution here?
And now we have ...
> I'm not taking a stand against NFS, I'm saying that it
> leaves much to be desired.
Yes, we know this. Yes, we know you like to implement web and simple
Internet solutions. Yes, you said ...
Brandon wrote:
> That's really the wrong conclusion. I specifically
> said I'm not a huge fan of NFS.
In response to my statement ...
Bryan wrote:
> After reading your statements, its as if you don't
> ever see a need for network filesystems in general.
*SO*, and fully ignoring the fact that this is _wrong_ to do on a
public mailing list, will you please tell me ...
Bryan asked:
> Then what do you use? Or more relevant to the thread,
> what do you see as a solution here?
Of which I now get (in this most recent response) ...
Brandon wrote:
> I don't know near enough details of the OP's problem,
> budget, and remaining time to implement to jump to a
> solution.
Okay, let's put that aside, and focus on ... (again) ...
Bryan asked:
> 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?
And if you couldn't or didn't want to answer that, I even offered
another aspect ... again ...
Bryan also/alternatively asked:
> Or what strategies do you use to _avoid_ that? Local
> home directories with rsync? Selective remote network
> filesystems as little as possible? What?
Now you've made another post "dancing around" the issue. This just
goes to the heart of what I said early on ...
Bryan wrote:
> 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.
And now it continues ...
> I'll fully admit I've done some interesting things with NFS
> such as diskless servers with FreeBSD, but it takes money
> to make it reliable and resilient.
But according to you, you don't like NFS.
According to you, you're not against network filesystems.
So, again, what do you use?
> Not exactly true, but therein I hit limitations on things I've
> actually done myself.
Exactomundo.
> There are some other ways available to export block devices
> over the network. GNBD is a project by Redhat that does
> it in the kernel (with userland tools to manage it).
Yes, but those _still_ have the same issues as any other "storage
area network" (SAN). Those don't "by-pass" the locking issues or
open directories, files, etc... of home directories and what-not.
You're throwing out "buzzword bingo" at this point, _not_ getting at
the _heart_ of the context.
> You can also try ATA over ethernet (AOE).
Which is ... tada ... a "SAN-like" approach. In face, I've run into
_so_ many people who think because they've gone to a Linux conference
and seen these things that ... tada! ... all our SAN issues are
solved!
God forbid if I bring up multi-targettable SAS as a "same closet SAN"
solution. All of the sudden the AOE preachers come out for battle!
WTF?!
Again ... buzzword bingo!
> NASA is using AOE and the Goddard Space Flight Center.
NASA uses a lot! NASA has all sorts of things. From traditional
SANs to MAID VTLs to countless other buzzwords. So what?
What does any of this have to do with the features required to mount
home directories and deal with the open files and locking issues of
remotely mounted home directories using network filesystems?
And if you don't want to answer that, then answer how you get around
using network filesystems for home directories? What strategies do
you use?
> I don't see any reason why I can't mention technologies
> I've never tried myself in case people might be
> interested and investigate the issue further themselves.
I didn't say you couldn't. If you would have stopped there, you'd be
fine. But you didn't.
Which is why I wrote ...
Bryan wrote:
> In case it didn't click ...
> I'm not trumping your offering.
> Many threads go all over a concept.
> This is not even moderating or criticism,
> as I am so guilty of abusing mailing lists
> myself in excess of anyone else.
> However, the detail is ...
> - Maintain the context of the question
> - That will offer solutions that address the question
> - Which involves people actually sharing what they used
> - And, most importantly, what actually worked
Which you immediately responded to with ...
Brandon wrote:
> I'm fairly sure I covered 1, 2, and 3 ..
> and 4 anecdotally.
And I'm sorry, I had to respond with ...
Bryan wrote:
> 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.
It was _not_ until later that you admitted you had no idea what was
involved. But beyond that, you didn't even see the "context" I was
trying to get you to see. You kept saying, "it works for others."
And you kept marginalizing the _very_key_ concepts I presented that
caused you to keep doing this. Hence ...
Bryan further wrote:
> 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."
Because ...
Bryan finalized:
> 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.
Of which I hope you understand the reason why it got to me ...
Bryan honestly wants you to understand ...
> 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.
And I beat the reasons why like a dead horse after that, just like I
did in my previous post. ;)
> That's a bit broad to say that one couldn't find a way
> to make it work.
Okay, I've pulled the gun ...
> Still talking out my @ss because I've never done this
> production but I have done it in testing and read of
> others doing it in production.
For *WEB* servers!
For shared *WEB* data!
*NOT* "home directories."
That's the "context" you have utterly obliterated!
Which is why you _refuse_ to answer and _ignore_ the questions ...
Bryan asked:
> Then what do you use? Or more relevant to the thread,
> what do you see as a solution here?
Or even ...
Bryan asked:
> 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 just even ...
Bryan also/alternatively asked:
> Or what strategies do you use to _avoid_ that? Local
> home directories with rsync? Selective remote network
> filesystems as little as possible? What?
And now we get ...
> You can use the DRBD device as the backing storage for
> a Xen guest
Okay, snapshots of the guest OS' virtual filesystem. Well, sort of I
guess. I mean, you still have the "open filesystem" aspect in the
guest OS.
But I'm game ...
> that serves up NFS.
But you don't like NFS? Now I'm confused. But that aside.
> You can migrate the guest with no downtime if you
> know you need to perform maintenance on the host.
Huh?
Unless my "snapshot" of the guest OS was made _exactly_ at the time
of the guest OS' "demise," then any "snapshot" is not going to have
the same open files, NFS locks and other "state" as the system that
went down. So instead of just having "hung" NFS clients, I will get
_corrupted_ writes as a result.
Again, and this is getting really, really old, I'm seeing repeat
themes of "web server" thought at work. Simple protocols of
read-only "open, serve out data, close now" type mentality, like HTTP
and FTP and the like work. That's not how desktop applications use
home directories.
> A significant risk is having the host fail unexpectedly
> while the guest is running on it.
Forget that. I'm just focused on the "guest failure" above. We're
not even worried about that yet. ;)
> Some people have _wildly_ different expectations of
> service uptime. You'd _never_ recommend the above
> to a bank;
Ummm, okay, NASA and now financial networks. Understand you've just
hit the two biggest parts of my experience. But that aside ...
> Banks don't like risk and are willing to pay to avoid it.
> Joe Schmoe running a SOHO might be perfectly OK with that risk.
Oh great, we're back to this.
Listen, I'm a professional. I don't tolerate negligence, much my own
negligence. It's not that it's about money.
It's about what _utterly_ "breaks."
What doesn't break for "web servers" _absolutely_ breaks for "Joe
Schmoes'" network with remotely mounted home directories.
> If anybody out there isn't doing their own research after
> getting advice from any source .. is begging for trouble.
Why did you just point the finger at yourself? Seriously!
Furthermore, didn't we have the whole discussion on "works for
people" and my whole little "97% v. 3%" tirade?
And with all that said, and sorry to get on my "high horse," but
there's a reason why I wrote two blog entries this year. One of them
is this little nugget, which explains _why_ I'm so "anal" on this ...
http://thebs413.blogspot.com/2007/08/open-source-solution-providers-code-of.html
Wouldn't it be nice if we _all_ could practice the rule of sharing
what we have first-hand experience with, _under_ the "context" of
someone's question, and get to solutions that "just work"?
Especially solutions that "just work" without the whole "works for
people" non-sense well outside the "context" of the original
question?
Without the side-stepping of, "oh, I don't like that, so I don't use
it" without any side-stepping of what actually works for you, for
that application?
And without marginalizing what someone _does_ have working, let alone
ignoring why he is actually _against_ the complexity involved to do
it?
> Yes, I've used NFS for exporting /home, exactly what you're
> claiming I've never done.
No, now you're putting words in my mouth.
I'm asking about either ...
- NFS failover, or
- some sort of "network filesystem" instead of NFS, or
- at least some "strategy" that "avoids"
network filesystems in general in the first place
You've ducked, dodged and basically marginalized that whole slew of
questions, of which I was just looking for 1 answer to 1 of them.
> Yes, I understand that NFS is full of pit-falls and
> that you can end up with a hosed mount.
> You don't know what I have and haven't done except for
> what I've told you. By all means, tell
> me my life story or stop with the personal attacks.
Okay, there's the key phrase ... "personal attacks."
We're done and I'm outta here .. PERIOD.
--
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