Subject: [nfsv4] directory delegations questions/suggestions

From: Spencer Shepler <[email-masked]>
Date: Thu, 23 Feb 2006 12:22:26 -0600

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

---

From: Mike Eisler <[email-masked]>
Date: Thu, 23 Feb 2006 12:47:27 -0800 (PST)

> directory delegations conditionally without failing the entire

makes sense.

> not be how easy it is to implement but more based on the server's 

ACLs, delegations, and layouts create ease of implementation challenges too.
As does RPCSEC_GSS and file system migration.

> workload or general policy setting.

Some servers might not be able to provide the new entry's directory cookie
efficiently, though as I pointed out in the con call, even
conventional UNIX servers know, somewhere, at the time a file is
created what its directory cookie is. Regardless, it would be 
reasonable to make the cookie optional.
This does mean that notifications would be useful only for updating name
caches and not caches of directory entries.

> on it and its relation to this incoming SETATTR?  

The server would need to have a pointer from the file to its parent directory.
Some file systems can do this; admittedly most cannot (just like most cannot
support ACLs). One of the reasons why some file systems do 
this today is so that users don't have to deal with inode numbers
or worse, file handle blobs for things like error diagnostics, and
auditing. 

So it is the ease of implementation again, but we've things in the current
and i-d specifications that are much harder than this.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 23 Feb 2006 15:39:11 -0600

> > directory delegations conditionally without failing the entire

I will send out a specific update for this change.

> reasonable to make the cookie optional.

I will send out a change for this as well to see if it makes sense.

Spencer