Why NFS servers generally have a 'reply cache' | Hacker News Reader

Why NFS servers generally have a 'reply cache'

utcc.utoronto.ca

28 pointszdw13 comments

> If UDP drops a NFS client's request to the server, the NFS client will resent it

I'm 100% sure this is a typo but the new meaning is hilarious anyway.

This article is plain wrong. The reply cache exists to provide idempotency for non-idempotent requests.

You need that with TCP just as much as you do with UDP. Otherwise, a TCP connection drop (or the failure of one server in an NFS server cluster) would lead to filesystem corruption.

By my reading the article says exactly what you said.

He even says in TCP it's used in TCP it's just relatively infrequent, by comparison to UDP.

Why isn't it TCP instead of UDP to mitigate lost packet issues?

you can tell NFS to use TCP

AFAIK you have to tell it to use UDP, because TCP has been the default in most implementations for a while. Even when I started with v2 in 1990(ish), the issues with NFS over UDP were already known.

The rough history is that NFS originally only supported UDP, likely for resource reasons (tcp buffers, for example, are expensive when you have < 64Mb of RAM) and because it was mostly used on local LANS.

This, and also NFS over TCP was quite slow when it was first introduced, because TCP checksum offloading was not common; as I recall it was about a 15% speed hit versus properly configured UDP, concomitant with higher CPU use, on Solaris 7 (SunOS 5.7).

TCP connections still can drop (your network interface could bounce, for instance), and with NFS, that won’t lead to filesystem corruption, or require special application-level handling.

Also, NFS supports clustered servers, so the machine that you sent the rename to might have crashed. The surviving machines need to know what happened with the rename, so when your client reconnects, it can resend the rename and get the right response code.

tl;dr because NFSv3 is a layer-violating mess of a protocol

It's a mess, but not because of layer violations. Contemporary file-access protocols were far worse in that regard, as is ZFS in a different stack. I remember the XID-cache mess all too well from my younger days, but it's not really a layering issue. It's exactly the kind of thing that a session layer is supposed to do. That functionality can't be kept in the transport layer in the case of clustered servers (which I was working on at the time). Please don't use "layer-violating" just because it sounds bad.

yeah but this is a hangover from v1 when UDP nfs was thought to be a good idea.

Wait until you see NFSv4...

Reply on news.ycombinator.com