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

Dave.Noveck@netapp.com

Subject: RE: [nfsv4] personal drafts of interest to NFSv4 WG
Date: Fri, 18 Feb 2005 16:17:05 -0500
Message-ID: <C98692FD98048C41885E0B0FACD9DFB840D37A@exnane01.hq.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>

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

How does the server make this test?  Some of the operations that 
will change a directory have stateids which would allow you to
make sure that the delegation and the requestor both map back to 
the same client, but a number of others do not.  Similarly the
delegated client should be allowed to do a READDIR without 
causing a recall of a directory write delegation that he holds,
but you have the problem that READDIR has no stateid/clientid.

You could create new versions of a large number of operations and
add stateids or clientids to them, but this seems ugly especially as
as these would not be needed once sessions were adopted.

Another approach would be to use sessions for the comparison.
The result would be that directory write delegations would not be
supported without sessions being present, even though directory 
read delegations could be.  Normally we wouldn't like to have minor
version features dependent on one another but I think this is a 
case in which that might be the best alternative.  

-----Original Message-----
From: bwickman@citi.umich.edu [mailto:bwickman@citi.umich.edu] 
Sent: Friday, February 18, 2005 10:47 AM
To: Ted Anderson
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] personal drafts of interest to NFSv4 WG

> >         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-delega
tions-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

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