From: ray@us.ibm.com
Date: 05/10/99-03:10:37 PM Z
From: ray@us.ibm.com
Message-ID: <8525676D.006ECF27.00@D51MTA10.pok.ibm.com>
Date: Mon, 10 May 1999 15:10:37 -0500
Subject: Re: File Handle definitions-behaviors (version 2)
Please remove me from this mailing list.
Thanks
Ray Bills
Dept. G8P - IFS Development
253-4699
---------------------- Forwarded by Ray Bills/Rochester/IBM on 05/10/99 03:10 PM
---------------------------
Mike Eisler <mre@eng.sun.com> on 05/10/99 02:14:15 PM
Please respond to Mike Eisler <mre@eng.sun.com>
To: Devesh Shah <Devesh.Shah@eng.sun.com>
cc: nfsv4-wg@sunroof.eng.sun.com (bcc: Ray Bills/Rochester/IBM)
Subject: Re: File Handle definitions-behaviors (version 2)
> >> If the server can return a new filehandle to the client after a rename
> >> (and most other functions) it would reduce the number of cases where
> >> an EXPIRE would need to be returned.
> >
> >Right. This was discussed several months back, and the consensus appeared
> to be >that there would be an that indication (in the form of an attribute)
> to the >client whether RENAMEs would product new file handles, and if so,
> the client >would issue a compound op containing:
> >
> > COMPOUND {
> > RENAME A B
> > LOOKUP B
> > GETFH
> > }
> >
> >See Spencer's recent e-mail where he tries to capture the bit that says
> >whether the file handle is volatile through a RENAME or not.
> Why NFS clients would have to assume about the file handle (new or
> persistent) ?. I believe the protocol would be at its best when
> client assume a little about NFS server.
Review the archive. I believe it was suggested that RENAME results could, via
discriminated union, return an new FH, but there was a counter suggestion to
use an attribute instead. I didn't see any objections, so I'm assuming that's
the consensus.
After starting to prototype COMPOUND, thus far I find it is a cleaner way to
inject optional data in the response stream. With COMPOUND, the clients asks
for what it wants. With the V3 post-op attribute approach, the client may get
a bunch of stuff it doesn't care about.
So for RENAME, the client may not care that the fh changes, because the client
might not be maintaining name to fh cache. So forcing an fh upon it in the
RENAME results is a bad thing.
-mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:00 AM Z CST