<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I always ( and only ) feel compelled to reply to this group when
someone pontificates on some issue, criticizes individuals for not
doing some ( or many ) things in a way he approves. I used NFS. It had
its limitations and while annoying at times, I found those limitations
benefited me in ways I did not anticipate. It's true that I did not
face many of the issues most of you have to face.<br>
<br>
I guess it would helpful if Mark could list for each and every possible
job or task and variation thereof, the "right tool" or application for
that job. He can't. I've always believed that it was best for the
individual setting up and/or making use of a system to make that choice
and live with their choice until they decide they need to change for
reasons they see as appropriate.<br>
<br>
I think Mark is performing a service in initiating a dialog and
pointing out that there may very well be better tools available to do
"the job" ( don't we all already know that ), but may be going a bit
too far in pressing his point. NFS is not "just plain bad". The beauty
of programming and, to some extent system admin, was once and probably
still is that it allowed the individual to think freely and choose
their own approach to solving a problem.<br>
<br>
As has happened to me ( although people are wrong regarding this point
), I am now considered obsolete, not the right tool for the job, but
somewhat short of being "just plain bad". For many of you, including
Mark, the unfortunate truth is that the same thing will probably happen
to most of you sooner than you think or would like. Do we really lose
creativity and fail to adapt as we get older?<br>
<br>
P. Goodman<br>
<br>
<br>
Mark Musone wrote:
<blockquote cite="mid001701c66961$216ca3f0$07927e41@OP4" type="cite">
<pre wrap="">Oh, no don't get me wrong..
It's not somebody using NFS for some purpose that makes NFS bad.
It's that NFS is just plain bad..
In a nutshell, NFS is a "jack of all trades". NFS was made a long time ago
to solve a problem for which no solutions existed. This was back when hardly
anything had reliable, standard protocols, and when you had a 1Mbps coax
network was a huge deal.
Because of that, and the lack of anything even remotely "networkable", the
best solution was to use NFS. By using NFS, you could essentially turn any
program into a "networked" program without ever needing to deal with a
socket. You just use NFS as a wrapper..
With that said, NFS used (uses) UDP, because back then the networks were
simply too slow to handle TCP. NFS was quite unreliable, slow, and until
lockd appeared, file locking was non-existant. (yes, it uses TCP
now..whoopiee)
So whenever I talk about NFS, what's really important is what people seem to
gloss over, which is "What problem are we trying to solve". In terms of
"filesharing"..which I want to use the term loosely, because as I mentioned
before, NFS is actually used significantly more for networking than
filesharing. Please keep in mind, yes, you are _using_ filesharing with NFS
to be able to solve some problem. Just because you are using the filesystem
uses of NFS to solve a problem, does not necessarily mean you really are
using or need to use true filesharing. This goes back to my original
question of what problem are you trying to solve?? In the answer of
exporting a mail spool, the real problem is concurrent remote and
distributed email access..NOT sharing of a mail file..big difference, and
it's important to realize that.
So just talking about filesharing specifically, there is a continuum of
filesharing methods and solutions. Generally, there are two mutually
exclusive core needs when dealing with filesharing:
1. Speed ---Gotta get the files back and forth quickly!!
2. File Contention --Need to make sure that if two people write to the same
file, we can deal with it cleanly.
It is important to note that these are mutually exclusive. The better you
are at one, the worse you are at the other. Lets take a quick example of a
poor man's filesharing: cat'ing the file to a network pipe that just cat's
it to it's local filesystem:
System 1
"cat myfile | nc -u system2 55512"
System 2
"nc -u -l -p 55512 > myfile"
That's close to as fast as you can get, but if two people send the file at
the same time..big problems!!! You all have dealt with it I'm sure when
trying to deal with FTP and God forbid shared FTP upload locations. That's
another example.
That's one extreme, the one where speed is the most important and file
contention is least (or non-existent)
The other extreme is in all the fancy schmancy internet distributed file
systems, such as AFS (is it still even alive) and CIFS, and you can even
stretch your thinking with things like CVS and SVN. The key point is this
extreme, you are dealing with and assuming offline modifications of files,
synchronizing of information..etc..HUGE file contention issues..these are
all by the very nature of needing to compare literally bit by bit and
figuring out resolutions for conflicts, are very slow.
So where's NFS in all of this? Smack dab in the middle:
Kinda slow with filesharing (or one could say kinda fast with
filesharing)
Kinda ok with file contention (gotta love those stale nfs file
handles)
Other key facets of NFS -- all because we're dealing with a
FILESHARING application:
Hugely concerning about security
Need to deal with userid's, permissions
Need to deal with filesystem specific attributes
Need to deal with literally legacy way to doing things (NFS
handles built into the superblock..Wah??!!!!)
File locking is touch and go between heterogeneous systems
Mounts,exportfs,lockd,portmap..any more crazy applications?!
..And lastly, overall we're dealing again with a _legacy_
application, things like relying on portmap and RPC calls..hello..RPC dies
12 years ago. Is NFS like the _only_ thing that even still uses RPC??
So I think that my soapbox completely off the top of my head. Overall:
If you are needing _real_ filesharing, why pick a jack of all trades versus
using the correct filesharing application that is best suited for your
needs..it's all about using the right tool for the job.
Secondly, and most importantly, I'm less bashing NFS and more bashing the
_use_ of NFS for elements that should not be needed. Most people use NFS
again as a quick way to solve a networking problem versus using a _real_
networked approach. i.e. why in the world would people NFS mount a mail
spool versus read the email via pop or imap, a PROTOCOL designed
specifically for the type of data and metadata that is being served and
needed. Nowadays there's protocols for _everything_ and just like the above
statement, it's all about using the right tool for the job. Too many times I
see people bash Windows saying things like "I use Linux because it's the
right tool for the job", and then I turn around and see them use the
fat,bloated, and wrong tool for the job once they pick the OS.
Using the right tool for the job is not just about picking Linux, it's also
about using the correct application and knowing your problems and needs.
-Mark
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:nflug-bounces@nflug.org">nflug-bounces@nflug.org</a> [<a class="moz-txt-link-freetext" href="mailto:nflug-bounces@nflug.org">mailto:nflug-bounces@nflug.org</a>] On Behalf Of
Jesse Jarzynka
Sent: Wednesday, April 26, 2006 2:01 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:nflug@nflug.org">nflug@nflug.org</a>
Subject: Re: [nflug] NFS noac option
Mark Musone wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Oh. I guess I can directly give a quick answer with a question: what
</pre>
</blockquote>
<pre wrap=""><!---->problem
</pre>
<blockquote type="cite">
<pre wrap="">are you trying to solve that requires the need for nfs mounted mail
</pre>
</blockquote>
<pre wrap=""><!----> I don't have any. I just don't understand why someone using NFS for
an unintended purpose makes NFS bad.
</pre>
</blockquote>
<br>
</body>
</html>