[nflug] NFS noac option

Mark Musone mmusone at shatterit.com
Wed Apr 26 23:37:36 EDT 2006


Well, I guess it serves me right to write something off the cuff, exactly
what I was afraid of. I think you missed a large part of my point, which I
tried to catch up with at the end of my email. I'm not trying to get people
to stop using NFS as much as taking a different perspective on things. Feel
free to ignore me. :-)

 

It's the use of NFS, or rather any filesharing for things that really
shouldn't be used nowadays. You are asking for specific bad things and solid
proof as to why NFS is bad, and like I said it's about solving the correct
problem.  It's about saying "here's my problem, what's my solution" instead
of saying "here's my solution, what problems can I fix". Feel free to give
me some specific problems and I'd be happy to suggest something that may be
more optimal for that task. Maybe I can explain it better with some
examples:

 

As an example, years ago before networked database servers we used to use
flat files and DBM files (if we wanted to get really crazy) for our database
needs. There was no Mysql, MSQL, postgres..etc.. So, how did we make it so
that we could have multiple "database clients"??? Simple, use NFS!

 

We'd make one machine an NFS server with the flat "database" files, and all
the other machines would remotely mount the machine and update the same file
using the typical .lock type of contention resolution. It was simple. It
"worked". Later if anybody would tell me of using a networked database
server like Mysql, I'd laugh at him and tell him they're crazy!!! NFS works
great! I have tons of benchmarks for it! It works seamlessly! NFS has been
in use forever! It works with NIS and LDAP! It's STABLE! Sure, if you have
the systems configured poorly, NFS can have "bad" performance but overall
it's got great performance!.  (all this sound familiar??)

 

However, nowadays we'd all laugh at that NFS person, now that we have such
things as Mysql and networked SQL. We know that using the mysql approach is
a ton better, even if we're just storing BLOBS with just one or two columns
(i.e. making pretty much a file sharing database). Why is Mysql so much
better, because it's a protocol that's _context_ sensitive to the metadata
that is being used. Same goes for IMAP. IMAP is simply an email-centric file
sharing protocol. You don't load up blocks of data in IMAP, you ask for an
email Header, or Envelope, or Body, or Attachment. You can't do that in NFS.
In NFS you simply get that whole file. The NFS server says "here you go, do
what you want with it". NFS is very dumb. Nowaday's there are _smart_ ways
of accessing data via network connections. We no longer need dumb, flat
filesharing. (unless of course you _really_ do want to share files, then
sure, it's fine if that's the problem you are trying to solve). There are
often specific protocols and mechanisms nowadays that optimize the
information and requests. Just because you can transfer a 10G file at wires
speeds does not necessarily mean it needs to be done. For example, to mark
an email message as "Read", you need to simply add a single header line in
the email message. Using NFS, you would roughly transfer the entire email
message (lets say it's 1M) to the client, it'll update the one line, and
send it back. Yes, you can send that information _real fast_, arguably as
fast as possible. But what If I said that _none_ of that needed to be done
if you just sent a single IMAP command to the server to mark it as read.
You'd need to only send about 20 bytes to the server. Now comparing the two,
it's no question as to what is faster, has better performance, has less
network and system impact..etc..etc..Again, I'm not questioning NFS, I'm
questioning the need for network filesharing solving this task to begin
with.

 

Another example is that I have heard many times and know individuals that
have setup SAMBA in order to do filesharing between two Linux machines. It's
actually not uncommon. As many of you would probably say, it's not quite the
"right" way to solve that problem (maybe we mean more efficiently or a dozen
other words than "right"?). Why does that person do it? Usually they don't
know of NFS or know how to set it up, so they use what they know and feel
comfortable with. Someone telling him to use NFS will usually get a response
of what I'm getting "What's wrong with SAMBA? I did benchmarks, it works for
reasons XYZ. Prove to me why SAMBA is bad", when in reality we're just
trying to help and give them additional information and an additional
perspective. 

 

As for some specific benchmarkings mentioned. Simply downloading a file does
not constitute proper benchmarking. You need some good concurrency and
alternative things to compare it to. What was the speed of the same file via
a HTTP GET?? (again, taking a different perspective, HTTP is really just a
read only file sharing protocol..actually quite fast..). or how long did
FTP'ing the file take? Now how about 10,000 files and about 100,000 random
retrievals. The last thing you want to do is download a large file and say
"oh, it works! And it's fast!!!"  Heck, you could possibly get 2 people on
the system sharing files and the whole thing can go to pot due to
contention, not to mention you have no base network alternative to compare
it to. 

 

Lastly, I was talking about Unix RPC. Theres a reason why nobody uses unix
RPC anymore..comparing SMB, Windows, or even SOAP is like comparing apples
to oranges. 

 

Please do not take me the wrong way, I do not intend on starting a flame
war,  I'm just trying to help get people to see things a little differently,
and some could say non-conventionally. Like when I tell them HTTP is really
just a read only file sharing protocol, they look at me like I'm crazy.. :-)


 

Please also do not take offense to me saying "Right way" or "Wrong way". I'm
not questioning or even saying anyone's way is right or wrong, that is not
my intention. If it works, GREAT!

 

I hope to help,

 

-Mark

 

  _____  

From: nflug-bounces at nflug.org [mailto:nflug-bounces at nflug.org] On Behalf Of
ptgoodman
Sent: Wednesday, April 26, 2006 7:16 PM
To: nflug at nflug.org
Subject: Re: [nflug] NFS noac option

 

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.

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 the choice and live with their
choice until they decide they need to change for reasons they see as
appropriate.

I think Mark is doing a service in initating a dialog,


Mark Musone wrote: 

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: nflug-bounces at nflug.org [mailto:nflug-bounces at nflug.org] On Behalf Of
Jesse Jarzynka
Sent: Wednesday, April 26, 2006 2:01 PM
To: nflug at nflug.org
Subject: Re: [nflug] NFS noac option
 
Mark Musone wrote:
  

Oh. I guess I can directly give a quick answer with a question: what
    

problem
  

are you trying to solve that requires the need for nfs mounted mail
  
    

    I don't have any. I just don't understand why someone using NFS for 
an unintended purpose makes NFS bad.
 
  

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.nflug.org/pipermail/nflug/attachments/20070525/f203c4fa/attachment.html
-------------- next part --------------
_______________________________________________
nflug mailing list
nflug at nflug.org
http://www.nflug.org/mailman/listinfo/nflug


More information about the nflug mailing list