From: Mark Hemment <markhe@veritas.com>
Subject: Reply-cache
Date: Sat, 9 Aug 2003 15:25:44 +0100 (BST)
Sender: nfs-admin@lists.sourceforge.net
Message-ID: <Pine.LNX.4.33.0308091522540.1062-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: <nfs@lists.sourceforge.net>
Errors-To: nfs-admin@lists.sourceforge.net

  A few NFS reply-cache questions, and possible answers.  Any feedback
would be appreciated.

1) Is a reply-cache needed over a reliable transport (TCP)?
     Yes.  Possible for a client not to receive a response due to a
   disconnect.  When re-connects, will retry the operation.  Need to trap
   this.

2) Cache look-up before checking for a client's export entry?
     The reply-cache look-up/resource-allocation occurs from
   nfsd_dispatch() - before the exp_get() check in fh_verify().  This
   allows for an attacker to fill the reply-cache with 'bogus' entries,
   reducing it usefulness.  As NFS servers are either accessible only on
   an intranet, or behind a firewall (unlikely?), this is not a serious
   problem.
      Partial fix is in nfsd_cache_lookup(), after checking 'type', test
   if rq_client is NULL.   Not ideal, but will catch most cases.
      Full fix is to move call to nfsd_cache_lookup() into fh_verify()
   (and anywhere else needed(?)) after the exp_get_fsid()/exp_get().
      If this is consider an issue, shout and I'll do a patch.

3) For non-idempotent operations, hold an "inprogress-entry" in the
   reply-cache?
      This would really only be for read operations, and possibly getattr,
   over an unreliable transport (UDP).  On a 'busy' server, response
   times may vary considerably; by trapping retransmitted requests which
   are in-progress, the 'busy' server will not be further overloaded.
   Note: I have no data to back this case up!  Does anyone have some
   hard-data/references on this?
      Ideally, the 'inprogress' entry would be dropped _after_ the
   response has been sent.  With the current design, nfsd_dispatch() calls
   nfsd_cache_update() before returning to the RPC code for a call to
   svc_send().  A callback hook after svc_send() would be useful....

Thanks,
Mark


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs