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

TedAnderson@mindspring.com

Message-ID: <42160484.1030101@mindspring.com>
Date: Fri, 18 Feb 2005 10:06:44 -0500
From: Ted Anderson <TedAnderson@mindspring.com>
Subject: Re: [nfsv4] personal drafts of interest to NFSv4 WG

On 2/15/2005 20:33, Noveck, Dave wrote:
...
> From: Spencer Shepler [mailto:spencer.shepler@sun.com]
> Sent: Tuesday, February 15, 2005 7:38 PM
...
>         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

I like this proposal because it includes specification of write
directory delegation and strips out notification behavior.

Is the client response to a directory CB_RECALL likely to have
sufficiently similar behavior that the code paths could be shared?
Specifically, for a write file delegation recall, the client must store
back dirty file data.  In the case of a directory, the response would
involve sending cached updates in the form of directory modification
operations.  These are different enough that some aspects of the
server's structure could be impacted.  Though I don't have any specific
problem in mind, but I am particularly concerned generally about locking
of structures related to the directory being delegated / accessed /
recalled.  So even if the protocol is agnostic to client/server code
probably can't be.

The idea of returning dir_write_delegation4, limiting the amount of
space to allocate, makes sense because the directory write delegation is
essentially a proxy for the file delegations of newly created children.
Also, it is much more effective to report space errors at open/create
time, when applications are generally better prepared to respond to
errors, than in response to a write syscall.  It seems like this
mechanism would facilitate that sort of control.

     struct dir_write_delegation4 {
	/* amount of space allowed for all files created */
	nfs_space_limit4  space_limit;
	/* number of directory entries allowed to be created for
	 * this directory before committing OPENs to server */
	uint32_t          dirent_limit;
     };

Does the dirent_limit refer to net new files?  If a client receives a
limit of 10 entries, and it creates 9 files local, then deletes the 9,
can it create another 9 without contacting the server?

What about subdirectory creation?  Are there any special limits on that?

 > 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?

I understand that the expected lifetime of a newly created file is quite
short as a majority of file creation operations are for temporary files.
Is the same true for newly created directories?  This isn't intuitive to
me.  To what extent is it true?

Whole-tree directory write delegation only applies to a newly created
directory, or did you mean to suggest that it would be possible to get
delegation on a whole existing tree?

Ted Anderson

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4