From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 12/28/02-07:04:41 AM Z
Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A070A7F@SILVER.nane.netapp.com> From: "Noveck, Dave" <Dave.Noveck@netapp.com> Subject: Comments on draft-ietf-nfsv4-repl-mig-design-00.txt 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."
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:46 AM Z CST