All-0's stateid and accessing a file in a stateless way

[J. Bruce Fields]

On Thu, Jul 17, 2008 at 01:31:52PM +0200, DENIEL Philippe wrote:
> Hi to all,
> 
> after my question related to the "all-0's" stateid in OP_WRITE4 and 
> OP_READ4, I thought about the possible use of this. The server I am 
> developing can work as a Proxy, for the moment it is just a NFSv4 proxy: 
> it makes NFSv4 request and answer only in NFSv4, it doesn't re-export in 
> NFSv2 or NFSv3. This is a strong limitation. The reason for this is the 
> NFSv4 OPEN semantics that requires
> the filename which is incompatible with the stateless mechanisms in 
> NFSv2/NFSv3. This ALL-0 stateid feature give me a new hope on this but I 
> need your opinion, I would not like to rely on something which is a side 
> effect of the protocol or a bad interpretation from me.
> 
> My question is this one: if I know the filehandle for a file, I will be 
> able to read and write to it, with all-0 or all-1 stateids, I will not 
> require a OP_OPEN4 to be performed to get a valid stateid. This way, I 
> can read and write, just by knowing it FH, in a way similar to the 
> "NFSv3 old style way of making I/O". It this true ? Did I misunderstood 
> something on this aspect of the protocol ?

One possible problem: it's not clear to me that servers are required to
actually accept special stateid's.  For example: "For a READ with a
stateid value of all bits 0, the server MAY allow the READ to be
serviced subject to mandatory file locks or the current share deny modes
for the file."  Note the MAY--that makes it sound to me like a server
*could* just fail any READ with a special stateid, if it wanted to (with
what error, I wonder?).  In practice I bet all server's actually accept
them (the linux server does, at least), so this may not be a problem.

--b.