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

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 15 Feb 2005 20:33:00 -0500

>        Title           : Implementation Guide for Referrals in NFSv4
>        Author(s)       : D. Noveck, D. Noveck

Don't know how this happened but I am not suffering from Multiple
Personality Syndrome (at least I don't think I am).  Carl Burnett
is the co-author of this draft.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Tuesday, February 15, 2005 7:38 PM
To: [email-masked]
Subject: [nfsv4] personal drafts of interest to NFSv4 WG

The following personal drafts were announced today and will be
of interested to the working group.

        Title           : Implementation Guide for Referrals in NFSv4
        Author(s)       : D. Noveck, D. Noveck
        Filename        : draft-noveck-nfsv4-referrals-00.txt
        Pages           : 24
        Date            : 2005-2-14

        Title           : NFSv4.1: Directory Delegations
        Author(s)       : B. Wickman
        Filename        : draft-wickman-nfsv4-directory-delegations-00.txt
        Pages           : 21
        Date            : 2005-2-14

_______________________________________________
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: Ted Anderson <[email-masked]>
Date: Fri, 18 Feb 2005 10:06:44 -0500

On 2/15/2005 20:33, Noveck, Dave wrote:
...
> Sent: Tuesday, February 15, 2005 7:38 PM
...
>         Filename        : draft-wickman-nfsv4-directory-delegations-00.txt

"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

---

From: [email-masked]
Date: Fri, 18 Feb 2005 10:46:55 -0500 (EST)

> sufficiently similar behavior that the code paths could be shared?

I believe so, but it will probably differ from implementation to
implementation.

> recalled.  So even if the protocol is agnostic to client/server code

It depends on the server's perspective about the entity being
modified/locked as well as the structure of the underlying filesystem. If
you look strictly at the metadata being modified by any given operation
sent to the server, it will be time_modify or change regardless if the
attributes are associated with a file or a directory.  Am I not correct
here?  If so, the server logically just needs to prevent operations that
update time_modify or change unless they come from the client whose
delegation has been recalled and needs to flush the state back.

In this sense, the behavior is identical.  However I'm sure the way this
behavior is implemented from server to server may prevent easy translation
from files to directories.

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

I intentionally left this a little open ended.  Recall that the client has
the ability to grant an OPEN (for create) locally without contacting the
server until an application needs the fileid/inode number.  If the
application deletes the entry before it grabs the file inode, then it can
count as zero allocated entries.  However, the total number really created
(i.e., the client has issued a corresponding OPEN/CREATE to the server and
gotten a real fileid) plus the total number of pending proxied OPENs
should never exceed dirent_limit.

Now, it might be nice for the server to be able to communicate a new
dirent_limit to the client, but there really is no mechanism for this and
I'm not sure if it's necessary.  As far as subdirectory creation, I am
just assuming this falls within dirent_limit, though a separate limit
could be mandated I suppose.

> 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.)

> me.  To what extent is it true?

If I mentioned this in the draft, it was probably an oversight.  I do not
recall reading any studies about short directory lifetime, although the
result for files is pretty much well accepted.  I can take a look at
directory lifetime within some of my bodies of traces and get back to you.
My guess is that short-lived directories are frequently found in browser
caches, but no other cases come to mind immediately.

> delegation on a whole existing tree?

No, you should not be able to get a delegation on a whole existing tree by
owning a delegation at the root, in general.  This optimization can be
only be done for newly created directories and existing directories that
are empty.  This should probably be clarified.

Thanks for the input,
Brian