[nflug] NFS is bad!!?? No, not in the real world.

Wed Apr 26 17:12:31 EDT 2006

OK, NFS is Network File System, NOTHING else.  NFS make use of Remote
Procedure call (using portmap to map ports out as needed) You say that
RPC is outdated, have you even looked under the hood of windows? (RPC
(Remote Procedure Call for those not in the know) is all over the
place, from everything from the SMB (Server Message Block (i.e. CIFS,
samba) protocol to COM to .net)

NFS Performs VERY well with minimal CPU usage, is easy to setup, and in
larger systems works well with a centralized auth system like NIS or
LDAP, to maintain UID/GID consistency. 

True, like any system if you set it up poorly, it will run like crap,
loose your data and eat your firstborn,  but if you do the proper 
research, set up the server and clients appropriately and have a stable
network foundation (proper spanning tree setup, correctly sized
subnets, proper configurations on switches and servers, etc) then
things run remarkably well.

On friday I was at cybersource assisting pete with some ideas, and
performed a benchmark using bonnie++ to verify performance of a drive,
and did the same test over an NFS mount.  Of course NFS was slower than
directly on the drive,  but the benchmark ran at nearly max wirespeed
over NFS, showing the little overhead and very high performance of NFS.
The network was a simple 8 port 100Mbit switch, with all ports in use,
server machine had a 300GB Seagate SATA drive, native bonnie++ speeds
of about 62MB/second.  Across the NFS link the benchmark ran at
11.5MB/second for a 2GB filesize test. (11.5MB/sec for per char read
and write, and for streaming red and writes).  11.5MB/sec may not
sounds like much but for a 100Mbit/sec network the max theoretical
MB/sec is about 12.5MB/sec assuming no protocol overhead (100Mbit/8bits
= 12.5MByte/sec), so with an 11.5MB/sec benchmakr speed, protocol
overhead for NFS and the UDP traffic was a measly 8%.  All the while
the test was running, performance was good, no data was lost and CPU
usage was nominal.

So I have yet to see any solid proof as to why "NFS is bad".  Perhaps
your setup was poorly executed or you had a flakey or substandard
network, or poorly supported/tuned ethernet cards.

There are instances where other filesystems may be more appropriate for
the needs, like Oracles' OCFS2 (clusters requiring concurrent access to
files), or systems like Coda that allow disconnected operation, but in
a large portion NFS is SIMPLE, EASY, High Performance (when properly
setup), and STABLE.

Mark I, and I'm sure everyone else would love to see more concrete
examples as to why "NFS is bad", and the supposed "Right way" to do it.

--- Mark Musone <mmusone at shatterit.com> 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.
> 
> -- 
> Jesse Jarzynka
> Cyber Source
> http://www.jessejoe.com/
> http://www.thecybersource.com/
> _______________________________________________
> nflug mailing list
> nflug at nflug.org
> http://www.nflug.org/mailman/listinfo/nflug
> 
> _______________________________________________
> nflug mailing list
> nflug at nflug.org
> http://www.nflug.org/mailman/listinfo/nflug
> 

Dave J. Andruczyk

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
nflug mailing list
nflug at nflug.org
http://www.nflug.org/mailman/listinfo/nflug