Subject: Re: [nfsv4] personal drafts of interest to NFSv4 WG

From: Ted Anderson <[email-masked]>
Date: Fri, 18 Mar 2005 10:04:57 -0500

On 2/18/2005 10:46, [email-masked] wrote:
>>>        Title           : NFSv4.1: Directory Delegations
>>>        Author(s)       : B. Wickman
>>>        Filename        : draft-wickman-nfsv4-directory-delegations-00.txt
>>>        Pages           : 21
>>>        Date            : 2005-2-14
>>
>>"NFSv4.1: Directory Delegations", by Brian J. Wickman, from
>>http://www.ietf.org/internet-drafts/draft-wickman-nfsv4-directory-delegations-00.txt
...
>> > The server must not grant a read or write delegation on a direc-
>> > tory if any files within the directory are write delegated to
>> > other clients.  The server must not grant a write delegation on a
>> > directory if any files within the directory are read or write del-
>> > egated to other clients.
>>
>>I don't understand why file delegations should conflict with delegations
>>on the parent directory?  Can you elaborate?  What about child directory
>>delegations?  Does this restriction apply only to immediate children?
> 
> If a client has a read directory delegation and a file within that
> directory is write delegated to a separate client, then the client with
> the file delegation may delete the file without committing that delete for
> an extended period of time.  This means the client with the read directory
> delegation would have an invalidated DNLC.  Ditto for write directory
> delegation.
> 
> A client with a write delegated directory may delete directory entries
> without synchronously committing those deletes to the server.  If the file
> being deleted happens to be delegated to another client, then there is a
> disconnect between two clients' view of the filesystem.
> 
> This only applies to immediate children (i.e., files in subdirectories may
> be delegated to other clients.)

I reviewed the RFC and I don't see a client with a write open delegation 
for a file can delete it.  So I do not think a read directory delegation 
needs to conflict with write delegations on its child files.

For a write dir delegation, the situation is different.  This should 
allow the client to remove files in the directory, but section 9.4.4 
says that removing a file should recall its open delegations.  So either 
the client would have to do this recall (not a good choice) or the 
server would have to prevent such delegations while the parent dir is 
write delegated to another client.

Is it possible for a client who knows a file's handler already (and so 
doesn't need to do a lookup) to do an open by file handle?  I recall 
something about this reopen operation, but maybe only CLAIM_PREVIOUS 
allows this.  If so the server would have to prevent such opens from 
returning a delegation if the parent dir (what about hardlinks?) is 
write delegated to a different client.

So I agree that write dir delegations conflict with child delegations, 
but I don't think read dir delegations need to.

Sorry for the long delay in responding to this thread,
Ted

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