Subject: RE: [nfsv4] directory delegations questions/suggestions

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 25 Feb 2006 16:53:56 -0500

> The first one is the error return for GET_DIR_DELEGATION.  As currently
> specified the operations is to return an error NFS4ERR_DIRDELEG_UNAVAIL
> if the server is unable/unwilling to provide a delegation.  I would
> like to suggest that in the case that a delegation is unavailable,
> that the operation not error out.  Instead, the results struct be 
> constructed such that one of the cases is a "no delegation" case.
> This will allow a client to build a compound that can collect
> directory delegations conditionally without failing the entire
> COMPOUND.

I can see the value of this, but there are also cases where the error 
behavior is desirable.  If I get a directory I might want to get the
current contents of the directory, once I know that those contents 
can be cached due to the directory delegation.  So a COMPOUND of
GET_DIR_DELEGATION followed by READDIR could be used and I might 
not want to bother with the READDIR if I have no delegation to
protect the contents.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Thursday, February 23, 2006 1:22 PM
To: [email-masked]
Subject: [nfsv4] directory delegations questions/suggestions

In reviewing the directory delegations portion of the minor version draft,
I have a couple of suggestions and questions.

The first one is the error return for GET_DIR_DELEGATION.  As currently
specified the operations is to return an error NFS4ERR_DIRDELEG_UNAVAIL
if the server is unable/unwilling to provide a delegation.  I would
like to suggest that in the case that a delegation is unavailable,
that the operation not error out.  Instead, the results struct be 
constructed such that one of the cases is a "no delegation" case.
This will allow a client to build a compound that can collect
directory delegations conditionally without failing the entire
COMPOUND.

The second item has to do with notification of directory entry additions.
So along with the new entry's name, there is directory entry location
information in the form of cookies.  Thinking through the implementation
details of how a server would implement this, it seems too onerous.
I realize that the server is not required to implement the notifcation
type but it seems as though the decision to suppor this feature should
not be how easy it is to implement but more based on the server's 
workload or general policy setting.

Maybe someone who has throught through more of the details than I can
make a suggestion of how to implement this efficiently.  My simplistic
view of an implementation would require the server to read the
directory after entry creation to determine the new entry's location
info and then provide that in the notification.  For large directories
that is expensive and basically an unreasonable overhead for any
size directory.  Other viewpoints?

Finally, the notification of attribute changes on the directory's entries
seems unattainable for implementation.  While the notification of new
entry can be implemented with some expense, the cost of object attribute
notification seems implausable.

The extreme case I am thinking of is where Client A has done a lookup
of an object in directory A and caches the filehandle for that object.
Client B comes in later and asks for a notification on directory A
and its object's attributes.  Between the time of Client A's interaction
and that of Client B, the server's cache of active objects has flushed
the fact that the filehandle was provided to client A for the object
in question.  So the server gladly instantiates a notification for 
the directory.  Later, client A decides to do a SETATTR on that object
and does so with the cached filehandle.  So, how does the server
realize that the directory in question now has the notification
on it and its relation to this incoming SETATTR?  
One might say that the server should not have provided the delegation
to begin with.  If that is the case, how does the server make that
determination without instantiating additoinal activity information
on disk about which filehandles have been provided to clients?

Spencer

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Sat, 25 Feb 2006 18:24:27 -0500

> not want to bother with the READDIR if I have no delegation to

Can you describe a case where you'd want a delegation on a directory
without actually needing the directory data?  And are such cases really
going to be more common than the obvious case where you need the data
but the delegation is optional?

It sounds a bit hypothetical.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Sat, 25 Feb 2006 22:29:18 -0500

> not want to bother with the READDIR if I have no delegation to

Time to add TRY / CATCH operations? ;-)

Cheers,
  Trond