[nfsv4] RFC: New DelegReturn_NoFH operation for NFSv4.2?

[Rick Macklem <[e-mail]>]

Hi,

I am wondering if others have found this a pita and are interested in
a new operation for NFSv4.2 to get around it.

Right now DelegReturn requires a CFH and delegation stateid.
I do not know why the CFH is needed, since it seems that the
delegation stateid should be sufficient?

This new operation would be the same as DelegReturn except that
it would not require a CFH argument.

Why am I interested in this?
- Lets assume a NFSv4.2 server that supports persistent FHs and
  multiple hard links (as most extant servers do).
- A client mounted to this server is removing a file for which it holds
  a write delegation and a bunch of dirty data.
Right now, the client must:
- Write the dirty data back to the server.
- DelegReturn
- Remove
because the client has no way of knowing if the file will be deleted
by the Remove (or alternately is just removing one of several hard links).

With a DelegReturn_NoFH, the client could:
- Do a compound RPC with
  Remove
  PutFH of file
- if the above returns NFS_OK, the file still exists and the client
  can continue to use the delegation, writing the dirty data back
  to the server sometime later (or maybe never, if the file gets
   deleted by a subsequent Remove).
or
- If the above returns NFS4ERR_STALE for the PutFH, the file
  has been deleted. It can throw the dirty data away and
  DelegReturn_NoFH the delegation.

A similar situation exists for Rename where the destination
already exists.

I find this scenario happens frequently during software builds.

So, what do others think  w.r.t. this new operation? rick