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

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 26 Feb 2006 09:18:31 -0500

> Can you describe a case where you'd want a delegation on a directory
> without actually needing the directory data? 

If someone finds that he is doing lots of lookups for directory and
decides he would like to cache the directory then he would want to
do a READDIR but only if he got a delegation.  With no delegation,
there would be no need to read the directory, only to satisfy the
individual lookup. 

> And are such cases really
> going to be more common than the obvious case where you need the data
> but the delegation is optional?

Don't know.

> It sounds a bit hypothetical.

Certainly it is hypothetical, but at least to me, it doesn't seem 
contrived.  But then again, it wouldn't seem contrived to me since 
I came up with (i.e. contrived) it :-)  Other opinions?

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]]
Sent: Saturday, February 25, 2006 6:24 PM
To: Noveck, Dave
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] directory delegations questions/suggestions

On Sat, Feb 25, 2006 at 04:53:56PM -0500, Noveck, Dave wrote:
> 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.

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.

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

---

From: "david m. richter" <[email-masked]>
Date: Sun, 26 Feb 2006 14:52:33 -0500 (EST)

> > [spencer]
> > 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.
>
> [dave]

	we've run into something that ends up being somewhat similar to
what spencer is talking about.  much as with file delegations'
open_delgation_type4 (NONE, READ, WRITE) being returned orthogonal to the
OPEN's error code, we are working on a "status"-type field returned in
the server's response to GET_DIR_DELEGATION.

	we then would not treat delegation-specific outcomes (NONE, READ,
DENIED (by policy), UNAVAIL (will never grant)) as errors.  more general
problems like a stale clientid or an XDR error, e.g., would still fail the
COMPOUND.

	a very ugly, old, incomplete little sketch of my thoughts on
the rudiments of the GET_DIR_DELEGATION op is at:
http://www.citi.umich.edu/u/richterd/gdd.html.

	if need be, i beg all your pardon -- none of any of this is meant
to sound presumptuous in the slightest.

> > [bruce]
> [dave]

	is this a sort-of-special-case that could be handled by
client-side policy?  once the client notices all these LOOKUPs going on,
could the client construct two separate COMPOUNDs (one for the delegation
request, one for the readdir) and then only conditionally send the second
one?  it introduces another synchronous operation, but it's likely small
potatoes compared to the problem-LOOKUPs.

	thoughts?

	d
	.