[kwlug-disc] The sweet(?) smell of power supplies

Cedric Puddy cedric at ccjclearline.com
Mon Apr 7 23:01:25 EDT 2014


On 2014-04-07, at 8:15 PM, unsolicited <unsolicited at swiz.ca> wrote:

> It wouldn't, except ...
> 
> Seems to me some long time ago I was reading about pros/cons of NFS. Including more robust at reconnection, but could be slow about doing so.

You can either mount NFS volumes sync or async -- in sync mode, if you get disconnected, then all attempts access filehandles get blocked on disk IO, and hang until the NFS server becomes available again, or you reboot your computer.  In async mode, if you get disconnected, then the filehandles get dropped, and let the corruption fall where it may (and good luck to you finding it later -- only mount async if you know your application(s) can handle it)

If you reboot an NFS server with sync mounts on it, then all the file handles on the server side are gone, so be prepared to reboot every client as well.

So, I'm not sure what they mean about "more robust on reconnect" but the above is my practical experience from running NFS in semi-conductor design shops, where NFS remains the standard method of sharing files out to build/simulation farms.  Just never, ever, reboot the NFS server casually, keep the LAN more-or-less online, and your users will give you a decent grade.

SMB is sort of stateless, in that it can have locks, and can have files open, and your access to those files can survive the reboot of a server without causing corruption (eg: you are working on a document, and someone reboots the server, it comes back up, and then you go to save your document -- SMB?  No problem.  NFS Sync mounted?  You probably dead.)

SMB, er... CIFS, is a much more baroque, complex protocol -- you want a simple listing of a directory with a handful of objects in it?  That could require upwards of 60-100 Kb of data exchange.  NFS?  Probably less than 1 Kb.

NFS has a lot of popularity in VM environments -- VMWare, XenServer, KVM, etc -- because it's ultra-low overhead, easy to implement, etc.  iSCSI is similarly popular, again because it's low overhead, and mostly gets out of the way.   The key to happiness in NFS (and networked filesystems generally) is just to make sure your file server is very, very, very stable (say, by getting a really nice filer that has redundant everything, and has been engineered to never crash).

Just a couple thoughts,

  -Cedric

> Could also have been a comparison / commentary against Samba, at the time, too. Heartbeat? Disk hit in worst possible place?
> 
> But a disk is a disk, and a filesystem is a filesystem. If there are problems, probably other issues in play, such as timeouts. Client / server versions / happiness / glitch-free connectivity. (Network saturation? Appears as an NFS issue but delving underneath may be revealing to non-NFS issues, like timeout?)
> 
> I wonder if some connectivity / file systems beat upon hard drives harder than others?
> 
> And ... hard drives have become problematic. IDE days, most seemed to just work forever. Hasn't seemed to be the case for some years though. I've wondered if since buying an SSD is building in requirement to replace (in 4'ish years?), some of today's hard drives, and lack of quality thereof, is all that different.

> 
> 
> On 14-04-07 04:17 PM, Andrew Kohlsmith (mailing lists account) wrote:
>> On Apr 7, 2014, at 3:23 PM, chaslinux at gmail.com wrote:
>>> The one thing I've wondered is if using NFS might have contributed
>>> to the hard drive's smart errors (after about 1 year of use)... I
>>> doubt it, but since I haven't done any NFS since... The drive was a
>>> 1TB Seagate. Current 2TB has been great for several years (bought
>>> it when hd prices were crazy low - $69).
>> 
>> Why would disk access through NFS stress a drive any more than local
>> disk access, or access through something like Samba or another
>> networking standard?
> 
> 
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org

|  CCj/ClearLine - Hosting and TCP/IP Network Services since 1997
|  118 Louisa Street, Kitchener, Ontario, N2H 5M3, 519-489-0478x102
\________________________________________________________
   Cedric Puddy, IS Director            cedric at ccjclearline.com








More information about the kwlug-disc mailing list