Good argument!

Though my window right now I can see the building of a company that shifts multiple TB of data though NFS every single day. I used to work for them. They would disagree about NFS as a protocol being unreliable.

There are lots of things around NFS that may cause unreliability such as network problems, unreliable hardware, duplicated reverse DNS, Underspecd servers, and so on. NFS itself is at least as solid as CIFS, iSCSI, NBD, SSHFS and rsync.

Please elaborate on why you believe NFS is unreliable. On a professional level I'm interested to know. I suspect the issues you believe are caused by NFS are actually something else.

At the risk of feeding the troll...

NFS's biggest problem is lack of security. It uses a "trust the client" model, which basically boils down to IP address protection. If your machine can mount the filesystem then you have pretty much total control of that filesystem. Given that NFS was originally just UDP then this wasn't much protection at all. Modern NFS can be run over TCP and the linode network design means that IP spoofing isn't a risk. (The secondary risks of the NFS security model really apply to larger environments with multiple security realms and wouldn't impact a linode model too much). Later versions of NFSv3 and NFSv4 can use kerberos security, but linode won't want to go into that hassle.

Related to this is how NFS talks over the network. It is an "RPC"-aware protocol and so uses the RPC portmapper to assign network ports. Today NFS might start up on port 33976 but on the next reboot it'll be on port 42146. Clients would contact the portmapper and ask "where is NFS?" and be told the port to talk to. This, unfortunaly, made it hard to work with firewalls because you never knew what port to open up. More modern versions can be forced to a fixed port.

There's a potential issue with file locking; the NFS protocol requires a lock daemon and a status daemon (sometimes the same process does both; rpc.lockd, rpc.statd). If a client wants to lock a file it needs all the other clients to agree "ok, you can lock it". If a client machine is down then this locking can take some time to timeout. File locking over NFS is a bit messy. This won't be an issue if each filesystem is only exported to one machine, or if you don't do file locking.

Related is the concept of local caching; when networks were slow it was common (still is!) to mount NFS fileservers with attribute caching turned on. This means that multiple runs of "ls -l" need not hit the fileserver as much. Which is fine unless one machine does a "chmod"; the other machines won't notice immediately until the cache expires. Again not a problem with a single machine, or if the filesystems are mounted with noac.

And, just to round this off, there's the 'not really POSIX' behaviour of some calls. Calls that are meant to be atomic may not be so on NFS (especially the older versions).

None of these are really "reliability" issues, though. As has been noted, NFS is in use in many many places, and more data than you can comfortably think about passes through NFS servers daily. If you want to share data across multiple machines then NFS is the defacto Unix solution (iSCSI exports block devices and so isn't suitable to have the same data shared read-write on more than one machine, same as a real SCSI disk or a SAN LUN can't be used by more than one machine at a time).

_________________
Rgds
Stephen
(Linux user since kernel version 0.11)

Wow, you've got that exactly backwards.

I would prefer just a block device attached to a single Linode, for simplicity. If someone wants to share it between Linodes they can do that with NFS/Samba/etc easily enough.

Thanks. I honestly didn't know most of that.

I find a couple of these to be arguments discouraging use of NFS... but I agree they don't sound like "reliability issues".

As of the parenthesed part... there are filesystems that can be mounted on multiple hosts at the same time. I agree they're not very common, and most of them is kind of specialized like ESXi's vmfs... but ones that claim to be general purpose do exist too. I guess it's time to spin up a couple of VMs and prod at those...

_________________
rsk, providing useless advice on the Internet since 2005.

It simply isn’t true that block devices (iSCSI, “real” SCSI or a SAN LUN) can’t be used by more than one machine at a time. They can — indeed, the SCSI protocol has commands intended to help with this — but the software layer above the block device needs to be aware of the shared nature of the device. Typically this means you have to run a “SAN filesystem” (e.g. StorNext) that understands how to use a shared block device safely.

NFS doesn’t solve the same problems as a SAN would. For example, your NFS server will still be a single point of failure, unless it is actually a cluster of machines operating with shared storage (ideally a SAN; DRBD or similar is probably the best we can do on Linode at the moment, but that allows unpleasant split-brain situations to develop under some failure conditions, which can require difficult data recovery or cause data loss).