3 ms·

This is a really detailed writeup and a huge amount of effort clearly went into the post. The NFS maintainer seems to agree that this was a bug worth fixing. B

This is a really detailed writeup and a huge amount of effort clearly went into the post. The NFS maintainer seems to agree that this was a bug worth fixing. But I think I'm missing something - doesn't the specification say that the observed behavior (the file handle having gone stale) is acceptable, based on this snippet: > A filehandle may or may not become stale or expire on a rename. However, server implementors are strongly encouraged to attempt to keep file handles from becoming stale or expiring in this fashion. So, is it more of a 'the specification isn't sufficient for real world usage' kind of fix, or was something actually broken?

misnome 6y ago
I understood that it’s an acceptable Server response, as per spec, but it’s a bug on the client that it asks for the now-invalid file handle even though it’s had it’s delegation withdrawn - from the client’s perspective it has no reason to assume that the file even exists any more. And yes, this is an excellent writeup.
Someone 6y ago
“the specification isn't sufficient for real world usage” I think that sums up NFS reasonably well. “Let’s make the API connectionless and stateless; that simplifies things” is true, but implementing Unix semantics, where files can be opened or closed, file deletes change state, file deletes aren’t seen by open file handles, programs want to do record locking, etc. on top of it? Maybe not the best of ideas. There’s a reason S3 isn’t a file system. (See also The UNIX Haters Handbook chapter on the Nightmare File System)
- tinus_hn 6y ago
  Originally you could run with NFS as your only storage, even swapping on NFS. If the server rebooted the clients would get stuck but resume once it came back up. This requires some hard to deliver guarantees from the server.
  - Someone 6y ago
    From what I understand, that only worked if the processes making NFS requests kept retrying long enough. But yes, being stateless has the advantage that the server won’t lose connections, open file state, etc. across client or server restarts. That’s useful, but if you assume you have a file system (which NFS claims to be), and want to use those features, you’re asking for problems. NFS is aan example of “worse is better”.
    - tinus_hn 6y ago
      The idea was they’d keep trying forever which typically is long enough. The downside is if you retire a server all the clients that still have files open will hang.
- guenthert 6y ago
  NFS isn't stateless since NFSv3 was introduced more than 25 years ago. There was a remote fs before NFS which closely mimicked Unix file system semantic (AT&T's RFS). There's a reason you don't read much about it.

misnome 6y ago

I understood that it’s an acceptable Server response, as per spec, but it’s a bug on the client that it asks for the now-invalid file handle even though it’s had it’s delegation withdrawn - from the client’s perspective it has no reason to assume that the file even exists any more. And yes, this is an excellent writeup.

Someone 6y ago

“the specification isn't sufficient for real world usage” I think that sums up NFS reasonably well. “Let’s make the API connectionless and stateless; that simplifies things” is true, but implementing Unix semantics, where files can be opened or closed, file deletes change state, file deletes aren’t seen by open file handles, programs want to do record locking, etc. on top of it? Maybe not the best of ideas. There’s a reason S3 isn’t a file system. (See also The UNIX Haters Handbook chapter on the Nightmare File System)

tinus_hn 6y ago
Originally you could run with NFS as your only storage, even swapping on NFS. If the server rebooted the clients would get stuck but resume once it came back up. This requires some hard to deliver guarantees from the server.
- Someone 6y ago
  From what I understand, that only worked if the processes making NFS requests kept retrying long enough. But yes, being stateless has the advantage that the server won’t lose connections, open file state, etc. across client or server restarts. That’s useful, but if you assume you have a file system (which NFS claims to be), and want to use those features, you’re asking for problems. NFS is aan example of “worse is better”.
  - tinus_hn 6y ago
    The idea was they’d keep trying forever which typically is long enough. The downside is if you retire a server all the clients that still have files open will hang.
guenthert 6y ago
NFS isn't stateless since NFSv3 was introduced more than 25 years ago. There was a remote fs before NFS which closely mimicked Unix file system semantic (AT&T's RFS). There's a reason you don't read much about it.