[HN Gopher] Why NFS servers generally have a 'reply cache'
       ___________________________________________________________________
        
       Why NFS servers generally have a 'reply cache'
        
       Author : zdw
       Score  : 21 points
       Date   : 2021-04-10 02:10 UTC (1 days ago)
        
 (HTM) web link (utcc.utoronto.ca)
 (TXT) w3m dump (utcc.utoronto.ca)
        
       | formerly_proven wrote:
       | tl;dr because NFSv3 is a layer-violating mess of a protocol
        
         | KaiserPro wrote:
         | yeah but this is a hangover from v1 when UDP nfs was thought to
         | be a good idea.
        
         | notacoward wrote:
         | 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.
        
       | voiper1 wrote:
       | Why isn't it TCP instead of UDP to mitigate lost packet issues?
        
         | blibble wrote:
         | you can tell NFS to use TCP
        
           | notacoward wrote:
           | 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.
        
         | tyingq wrote:
         | 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.
        
       ___________________________________________________________________
       (page generated 2021-04-11 23:01 UTC)