Subject: Re: LINK and RENAME issues

From: Neil Brown <[email-masked]>
Date: Mon, 8 Nov 1999 14:33:46 +1100 (EST)

Mike Eisler wrote:
> This makes target directories second class citizens.
> 
> Consider that a client can do:
> 
> COMPOUND { putrootfh ; lookup "a" "b" "c" ; link dir "d" },
> 
> but in order to get 'dir', the client must incur a previous round trip of:
> 
> COMPOUND { putrootfh ; lookup "a1" "b2" "c3" ; getfh }
> 
> Considering the WG's charter, to improve performance over the internet,
> this shouldn't stand.
> 

It occurs to me that stateids are also "second class citizens".
In his initial proposal for Compound Operations:

http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/0065.html

Brent Callaghan suggested that LOCK/READ operations would be a useful
consequence of Compound Ops. e.g.

1. PUTFH 0x0123456
2. LOCK 0 4096
3. READ 0 4096

I think that given the WG's charter as mentioned above, this would
still be considered a good thing to have, but it is currently not
possible due to the need to pass a stateid from LOCK to READ.

This could be remedied by raising stateids to a similar status to file
handles, and passing them between ops as 'current state id'.

As a stateid is always used in the context of a filehandle, it would
seem to make sense to allow there to be a 
     current file handle - current stateid
pair, and a 
     saved file handle - saved stateid
pair.
PUTFH would take a filehandle AND and stateid as args (stateid could
be 0 if not wanted) and would set cfh and csi:

   PUTFH:  filehandle, stateid -> (cfh) (csi)
similarly SAVEFH and RESTOREFH would save and restore them both:
   SAVEFH: (cfh) (csi) -> (sfh) (ssi)
   RESTOREFH:  (sfh) (ssi) -> (cfh) (csi)
and GETFH would return them:
   GETFH: (cfh), (csi) -> filehandle, stateid

Then every OP that needs a stateid: CLOSE, DELEGRETURN, LOCK, LOCKT?,
LOCKU?, RENEW, SETATTR, WRITE, READ, would use (csi) instead of
stateid. 
Also, every OP that returns a stateid would set (csi).  The only
awkwardness here is that OPEN can return two stateids, one for the
open and one for a delegation.  The open stateid would be stored in
(csi) and the delegation stateid, if present, would be returned as it
currently is.

NOTE: while writing this I noticed:

   1/ There is inconsistancy in draft-02 about whether an owner or a
   stateid is passed into LOCK, LOCKT, LOCKU.
   For LOCK, the SYNOPSIS and the ARGUEMENT say different things.
   LOCKU and LOCKT suggest "owner" in "struct LOCK4args" while the "RPC
   definition file" says "stateid".  I assume stateid is intended.

   2/ I notice that RENEW and DELEGRETURN take a stateid without any
   filehandle for context.  This implies that stateid's are assumed to
   be unique across all files, and not to be read in the context of a
   particular file as understood by Dave Noveck in 

    http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/1857.html

(and Yes, there is a similarity between this idea and the one that
Dave was responding to in 1857.html, but this one seems much gentler
and would be helpful independantly of that one).

NeilBrown