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

bwickman@citi.umich.edu

From: bwickman@citi.umich.edu
Date: Fri, 18 Feb 2005 10:46:55 -0500 (EST)
Subject: Re: [nfsv4] personal drafts of interest to NFSv4 WG
Message-ID: <Pine.BSO.4.58.0502181019320.28947@citi.umich.edu>

> >         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
>
> Is the client response to a directory CB_RECALL likely to have
> sufficiently similar behavior that the code paths could be shared?

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

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

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.

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

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.

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

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.

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

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

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