Subject: Comments on draft-ietf-nfsv4-repl-mig-design-00.txt

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 28 Dec 2002 05:04:41 -0800

Section 4.4: While I agree with what is written here, I think
this would be better put in a more general context of sending 
over a small set of changes to an existing file system without
sending over more than you have to.  Sending the changes to a
particular is just one (very important) instance of that.  Others
are changes in locking state (files opened and closed), renaming
of files, changes to some of the attributes of a file, etc.

Section 4.5, last sentence: Suggest replace by "This is currently
beyond our scope".

Section 6.1: This section deals with the most difficult case,
which is likely not to be used all that much.  There is another
issue with filehandles that is more circumscribed but is quite
important, because it will be needed in most contexts.  This is
the issue of retaining volatile file handles for the duration of
file opens.  In many environments this is necessary to make the
migration event transparent to the client (e.g. if a file is 
renamed while open, the normal volatile handle recovery path 
will fail or result in the wrong file being accessed).

So there are two issues to be dealt with.  First, even where 
we don't have persistent filehandles, the set of flehandles for
open files must be transferred so that the destination server can
honor them on a temporary basis until the file is closed.  This
would be done, not by cracking the filehandle information, but simply
by treating these files as opaque, saving a table of them and mapping
each opaque handle to its "real" fh counterpart on the destination
volume.  The details are up to the server implementation but the 
migration protocol needs to enable this by providing the raw fh,
even where persistent filehandles are not possible or desired.

The other issue is preventing fh conflict.  Without some co-ordination
mechanism it possible that a source fh (associated with an open
file) might be the same as an fh of some other file on the destination.
The migration protocol needs to address this issue somehow.  For
example, if servers were to prefix their normal fh's with their IP
address (and just not look at that part of the handle under normal 
circumstances), then the troublesome conflict could not exist.  So
perhaps the migration protocol should allow servers to negotiate
this issue by allowing them to simply declare that all of their handles
have some particular prefix, allowing the destination server to decide
whether safe migration is feasible under the cirsumstances, or the
user should be warned, or whatever.  Anyway, maybe that isn't the
right solution, but the document should mention the problem.

Section 6.3: This section is confusing, mainly because it uses
"filesystem" in two different senses, a set of files with the same 
fsid, and, something possibly bigger than that which is a unit
of management on the server.  Let's call these fs-prot and fs-srv.

One issue that is not mentioned in this section that can constrain
the server's ability to split an fs-srv into multiple fs-prot's is
the possible existence (current or future) of hard links between
directory trees that one would like to be in separate fs-prot's.
This is actually helpful since by declaring these trees as separate
fs-prot's, one prevents the establishment of hard links that would
make moving these fs-prot's to different machines impossible.

Another issue is that when one splits an fs-srv into multiple fs-prot's,
the space_avail and space_free attributes might reflect the fs-srv,
causing a migration to change these unexpectedly.  The document should
note this and basically leave this up to the administrator/implementation.

So I think what this section should say is that splitting an fs-prot
is and will remain out of scope (because it can't be done tranparently
to the clients and even if v4 were extended to allow it, the hard-link
issue would make it problematic).  It should point out, however, that 
the need for such a feature is reduced because v4 makes it much easier
to establish smaller fs-prot's, which is I think what the existing 
discussion is really intended to convey

Section 7.1: I would add here something like, "While it may be impossible
to detect all such problems in advance, the protocol should (via
server-server negotiation) provide notification of such issues as
early as possible, in order to avoid the inconvenience of an attempt
to migrate data which results in application failure."