alt Hacker News> The designers of NFS chose to make a distributed system emulate a highly consistent and available system (a hard drive), which was (and is) a reasonable tradeoff
I don't agree that it was a reasonable tradeoff. Making an unreliable system emulate a reliable one is the very thing I find to be a bad idea. I don't think this is unique to NFS, it applies to any network filesystem you try to present as if it's a local one.
> What does vi do when the server hosting the file you're editing stop responding? None of these tools have that kind of error handling.
That's exactly why I don't think it's a good idea to just pretend a network connection is actually a local disk. Because tools aren't set up to handle issues with it being down.
Contrast it with approaches where the client is aware of the network connection (like HTTP/GRPC/etc)... the client can decide for itself how long it should retry failed requests, whether it should bubble up failures to the caller, or work "offline" until it gets an opportunity to resync, etc. With NFS the syscall just hangs forever by default.
Distributed systems are hard, and NFS (and other similar network filesystems) just pretend it isn't hard at all, which is great until something goes wrong, and then the abstraction leaks.
(Also I didn't say io_uring solves this, but I'm curious as to whether its performance would be any better than blocking calls.)
Replies
I think it highly depends on your architecture and the scale you are pushing.
The other far-edge is the S3, where appending has just been possible within the last a few years as far as I can tell. Meanwhile editing a file requiring a full download/upload, not great either.
For the NFS case, I cannot say it's my favorite, but certainly easy to setup and run on your own. Obviously a rebooting server may cause certain issues during the unavailability, but the NFS server should be in highly-available. with NFSv4.1, you may use UDP as the primary transport, which allows you to swap/switch servers pretty quickly. (Given you connect to a DNS/FQDN rather than the IP address)
Another case is the plug and play, with NFS, UNIX permissions, ownership/group details, execute bit, etc are all preserved nicely...
Besides, you could always have a "cache" server locally. Similar to GDrive or OneDrive clients, constantly syncing back and forth, caching the data locally, using file-handles to determine locks. Works pretty well _at scale_ (ie. many concurrent users in the case of GDrive or OneDrive).
> Making an unreliable system emulate a reliable one is the very thing I find to be a bad idea.
It's the only idea though. We don't know how to make reliable systems, other than by cobbling together a lot of unreliable ones and hoping the emergent behaviour is more reliable than that of the parts.
Sure, at some point you have to let the abstraction leak. At the time Sun designed NFS, you could basically count on the fact that the server was some Solaris machine capable of multiple years of uptime on your LAN. Filesystems never made the transition to running over the internet because that was too unreliable and POSIX didn't really provide the right interfaces to expose that.
We're coming to the end of the road with that generation of OS design - MacOS is still Unix and thinks that it's running on a VAX. There's a reason why Macbooks don't come with a 5G modem: because programs would have to be aware of the underlying network. That's why it's inevitable that we'll move to something like IOS (or Android), because every program that uses the network has to handle not only failures but situations like being in flight mode or running on low-bandwidth mobile networks.
Do you have similar thoughts about iscsi?
So what if it is a fiber channel over ethernet drive?
I got bad news for you: they're always unreliable.
I've got a setup where the network filesystem is more reliable than the local filesystem. The local filesystem is running on a RAID-0 with fiber channel over ethernet and the network storage is a RAID-5 of a bunch of RAM block devices all linked over infiniband.
Your typical SSD these days is effectively a very complex distributed RAID, but it pretends to be a very simple local disk... and that's what most local filesystems are running on.
Honestly, NFS was designed to run over UDP originally. Failure was totally an option. When I was in school, the NFS filesystem was way more reliable than the local filesystems on the same computer. Yes, distributed filesystems are hard, but... NFS is comparatively straightforward for a lot of what passes for "reliable" these days.