[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-nfsv4-migration-issues

INTERNET-DRAFT                                         David Noveck
Expires: January 2005                       Network Appliance, Inc.

                                                          July 2004


                       Migration Issues for NFSv4
               draft-noveck-nfsv4-migration-issues-00.txt


Status of this Memo

     By submitting this Internet-Draft, I certify that any applicable
     patent or other IPR claims of which I am aware have been disclosed,
     or will be disclosed, and any of which I become aware will be
     disclosed, in accordance with RFC 3668.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups.  Note that
     other groups may also distribute working documents as Internet-
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
         http://www.ietf.org/ietf/1id-abstracts.txt The list of
     Internet-Draft Shadow Directories can be accessed at
         http://www.ietf.org/shadow.html.

Copyright Notice

     Copyright (C) The Internet Society (2004).  All Rights Reserved.















Noveck                    Expires January 2005                  [Page 1]


Internet-Draft         Migration Issues for NFSv4              July 2004


Abstract

     RFC3530 described an fs_locations attribute which can be used to
     allow an fs to migrate between servers without disrupting client
     access and to refer a client to another server providing access to
     a specified file system.  Initial implementation work for this
     feature has exposed a number of areas where RFC3530's handling of
     the issues leaves something to be desired.  This document makes a
     number of suggestions to remedy these issues when the NFSv4 spec
     next undergoes a significant revision, most likely in connection
     with implementing a new minor revision, such as NFSv4.1.

Table Of Contents

     1.   Introduction . . . . . . . . . . . . . . . . . . . . . . .   2
     2.   Attributes Returned by GETATTR and READDIR . . . . . . . .   2
     3.   Discussion of Error Codes  . . . . . . . . . . . . . . . .   4
     4.   Issues of Incomplete Attribute Sets  . . . . . . . . . . .   5
     5.   Referral Issues  . . . . . . . . . . . . . . . . . . . . .   6
          Acknowledgements . . . . . . . . . . . . . . . . . . . . .  15
          Normative References . . . . . . . . . . . . . . . . . . .  15
          Author's Address . . . . . . . . . . . . . . . . . . . . .  15
          Full Copyright Statement . . . . . . . . . . . . . . . . .  15


1.  Introduction

     Ongoing design work has exposed a number of weaknesses in the
     discussion of migration within RFC 3530.  While there does not
     appear any necessity to change any message formats or add
     operations, a number of migration-related issues should be
     addressed when the protocol is updated for v4.1.  The purpose of
     this document is to clearly lay out what needs to be done, so that
     any possible updates can be discussed as part of the process of
     formulating a spec for v4.1.  Some of the items discussed below
     might also be appropriate in the context of an update of the NFSv4
     spec in connection with going to a Draft Standard status.

2.  Attributes Returned by GETATTR and READDIR

     While the RFC3530 allows the server to return attributes in
     addition to fs_locations, when GETATTR is used with a current
     filehandle within an absent filesystem, not much guidance is given
     to help clarify what is appropriate.  In particular, there are a
     number of attributes which most server implementations should find
     relatively easy to supply which would be of value to clients,





Noveck                    Expires January 2005                  [Page 2]


Internet-Draft         Migration Issues for NFSv4              July 2004


     particularly in those cases in which NFS4ERR_MOVED is returned when
     first crossing into an absent file system that the client has not
     referenced.

     The NFSv4 spec should encourage servers to return the attributes
     fsid and mounted_on_fileid for absent file systems.  The specific
     reasons will be discussed below.

     On the other hand, a number of attributes pose difficulties when
     returned for an absent filesystem.  While not prohibiting the
     server from returning these, the NFSv4 spec should explain the
     issues which may result in problems, since these are not always
     obvious.  Handling of specific attributes is discussed below.

2.1.  fsid

     The fsid attribute allows clients to recognize when fs boundaries
     have been crossed.  This applies also when one crosses into an
     absent filesystem.  While returning fsid is not absolutely
     required, since fs boundaries are also reflected, in this case, by
     means of the fs_root field of the fs_locations attribute, returning
     fsid is helpful and servers should have no difficulty in providing
     it.

     To avoid misunderstanding, any new NFSv4 RPC should note that the
     fsid provided in this case is solely so that the fs boundaries can
     be properly noted and that the fsid returned will not necessarily
     be valid after resolution of the migration event.  The logic of
     fsid handling for NFSv4 is that fsid's are only unique within a
     per-server context.  This would seem to be a strong indication that
     they need not be persistent when file systems are moved from server
     to server, although RFC 3530 does not specifically address the
     matter.

2.2.  mounted_on_fileid

     The mounted_on_fileid attribute is of particular importance to many
     clients, in that they need this information to form a proper
     response to a readdir() call.  When a readdir() call is done within
     UNIX, the d_ino field of each of the entries needs to have a unique
     value normally derived from the NFSv4 fileid attribute.  It is in
     the case in which a file system boundary is crossed that using the
     fileid attribute for this purpose, particularly when crossing into
     an absent fs, will pose problems.  Note first that the fileid
     attribute, since it is within a new fs and thus a new fileid space,
     will not be unique within the directory.  Also, since the fs, at
     its new location, may arrange things differently, the fileid
     decided on at the directing server may be overridden at the target



Noveck                    Expires January 2005                  [Page 3]


Internet-Draft         Migration Issues for NFSv4              July 2004


     server, making it of little value.  Neither of these problems arise
     in the case of mounted_on_fileid since that fileid is in the
     context of the mounted-on fs and unique within it.

2.3.  fileid

     For reasons explained above under mounted_on_fileid, it would be
     difficult for the referring server to provide a fileid value that
     is of any use to the client.  Given this, it seems much better for
     the server never to return fileid values for files on an absent fs.

2.4.  filehandle

     Returning file handles for files in the absent fs, whether by use
     of GETFH (discussed below) or by using the filehandle attribute
     with GETATTR or READDIR poses problems for the client as the server
     to which it is referred is likely not to assign the same filehandle
     value to the object in question.  Even though it is possible that
     volatile filehandles may allow a change, the referring server
     should not prejudge the issue of filehandle volatility for the
     server which actually has the fs.  By not providing the file
     handle, the referring server allows the target server freedom to
     choose the file handle value without constraint.

3.  Discussion of Error Codes

     There are a number of cases in which RFC 3530 is either unclear or
     simply incorrect about the situations in which NFS4ERR_MOVED is to
     be returned.  Discussion of these issues has exposed the following
     problems, which should be addressed to provide greater clarity and
     correctness:

3.1.  Issue of when to check current filehandle

     In providing the definition of NFS4ERR_MOVED, RFC 3530 refers to
     the "filesystem which contains the current filehandle object" being
     moved to another server.  This has led to some confusion when
     considering the case of operations which change the current
     filehandle and potentially the current file system.  For example, a
     LOOKUP which causes a transition to an absent file system might be
     supposed to result in this error.  This should be clarified to make
     it explicit that only the current filehandle at the start of the
     operation can result in NFS4ERR_MOVED.

3.2.  Issue of GETFH

     While RFC 3530 does not make any exception for GETFH when the
     current filehandle is within an absent filesystem, the fact that



Noveck                    Expires January 2005                  [Page 4]


Internet-Draft         Migration Issues for NFSv4              July 2004


     GETFH is such a passive, purely interrogative operation, may lead
     readers to wrongly suppose that an NFSERR_MOVED error will not
     arise in this situation.  Any new NFSv4 RFC should explicitly state
     that GETFH will return this error if the current filehandle is
     within an absent filesystem.

3.3.  Inconsistent handling of PUTFH

     While RFC 3530 states (in section 6.2)  "The NFS4ERR_MOVED error is
     returned for all operations except PUTFH and GETATTR."  Despite
     this, RFC 3530 lists NFS4ERR_MOVED as an error that can be returned
     by PUTFH.  Any new NFSv4 RFC should delete this as a possible error
     for PUTFH.

3.4.  Inconsistent handling of GETATTR

     While, as noted above, RFC 3530 indicates that NFS4ERR_MOVED is not
     returned for a GETATTR operation, NFS4ERR_MOVED is listed as an
     error that can be returned by GETATTR.  It seems reasonable to
     allow NFS4ERR_MOVED to be returned by GETATTR's that do not
     interrogate the fs_locations attribute while maintaining the
     exception which allows GETATTR to be used to get fs_locations
     information by establishing the rules that GETATTR's which
     interrogate fs_locations (with or without additional attributes)
     will not return NFS4ERR_MOVED.

4.  Issues of Incomplete Attribute Sets

     Migration or referral events naturally create situations in which
     all of the attributes normally supported on a server are not
     obtainable.  RFC3530 is in places ambivalent and/or apparently
     self-contradictory on such issues.  Any new NFSv4 RFC should take a
     clear position on these issues (and it should not impose undue
     difficulties on support for migration).

     The first problem concerns the statement in the third paragraph of
     section 6.2: "If the client requests more attributes than just
     fs_locations, the server may return fs_locations only.  This is to
     be expected since the server has migrated the filesystem and may
     not have a method of obtaining additional attribute data."

     While the above seems quite reasonable, it is seemingly
     contradicted by the following text from section 14.2.7 the second
     paragraph of the DESCRIPTION for GETATTR: "The server must return a
     value for each attribute that the client requests if the attribute
     is supported by the server.  If the server does not support an
     attribute or cannot approximate a useful value then it must not
     return the attribute value and must not set the attribute bit



Noveck                    Expires January 2005                  [Page 5]


Internet-Draft         Migration Issues for NFSv4              July 2004


     in the result bitmap.  The server must return an error if it
     supports an attribute but cannot obtain its value.  In that case no
     attribute values will be returned."

     While the above is a useful restriction in that it allows clients
     to simplify their attribute interpretation code since it allows
     them to assume that all of the attributes they request are present
     often making it possible to get successive attributes at fixed
     offsets within the data stream, it seems to contradict what is said
     in section 6.2, where it is clearly anticipated, at least when
     fs_locations is requested, that fewer (often many fewer) attributes
     will be available than are requested.  It could be argued that you
     could harmonize these two by being creative with the interpretation
     of the phrase "if the attribute is supported by the server".  One
     could argue that many attributes are not supported by the server
     for an absent fs even though the text by talking about attributes
     "supported by a server" seems to indicate that this is not allowed
     to be different for different fs's (which is troublesome in itself
     as one server might have filesystems that do support and don't
     support acl's for example).

     Note however that the following paragraph in the description says,
     "All servers must support the mandatory attributes as specified in
     the section 'File Attributes'".  That's reasonable enough in
     general, but for an absent fs it is not reasonable and so section
     14.2.7 and section 6.2 are contradictory.  Any new NFSv4 RFC should
     remove the contradiction, while allowing servers to use the
     approach outlined in section 6.2.  It should also make sure that it
     is clear that the server may choose to return other requested
     attributes (e.g. fsid and mounted_on_fileid) rather than
     fs_locations alone.

     A related issue concerns attributes in a READDIR.  RFC 3530 already
     allows partial attribute return when rdattr_error is requested but
     indicates that if it is not requested, errors must be returned if
     not all requested attributes can be obtained.  When READDIR is done
     on a directory which contains mountpoints for absent fs's (either
     those that were once present and then migrated or simple
     referrals), this would seem to indicate that NFS4ERR_MOVED must be
     returned if the directory is in absent filesystem or any of the
     directory entries is the root of absent fs.  This seems unduly
     restrictive, but if that is the correct interpretation, it should
     be made clear that the exception indicated in section 6.2 does not
     apply in the READIR case, to avoid possible confusion.







Noveck                    Expires January 2005                  [Page 6]


Internet-Draft         Migration Issues for NFSv4              July 2004


5.  Referral Issues

     RFC 3530 defines a migration feature which allows the server to
     direct clients to another server for the purpose of accessing a
     given file system.  While that document explains the feature in
     terms of a client accessing a given file system and then finding
     that it has moved, an important limiting case is that in which the
     clients are redirected as part of their first attempt to access a
     given file system.

     Such redirection is often described as a referral event and
     implementing such a form of migration has many important
     consequences, which are not well explained by the presentation
     within RFC 3530, which often assumes that the client is informed of
     the migration event after one or more accesses within the file
     system for which a migration event occurs.

5.1.  Referral Situations

     When a particular client is directed to a new location upon first
     referencing a file system, the result is best seen, from the
     client's point of view as a referral, rather than a migration
     event, since the client contains no information derived from the
     file system before the migration occurred.

     Note that the above only refers to a particular client's point of
     view.  A given file system may be accessed by some clients and
     thus, when a migration occurs, those clients will see an ordinary
     migration event while other clients see a referral when they first
     attempt to access the subject filesystem.

     In the case in which none of the clients has referenced the subject
     file system at the time of migration, we have a pure referral
     situation, in that all that clients will ever see is the referral
     for an absent file system.  Given that clients can use such
     referrals to find the current location of file systems, servers can
     usefully provide such referrals when the filesystem in question
     never actually resided on the server.  Such referrals may allow
     implementation of some forms of  multi-server namespace, although
     NFSv4 support of a global namespace would require considerable
     additional work.  Nevertheless, an arrangement where the client
     addresses file systems in terms of the name of the filesystem on a
     server providing referrals may be valuable, because it allows the
     clients to isolate themselves from server configuration changes
     which move file systems from server to server.






Noveck                    Expires January 2005                  [Page 7]


Internet-Draft         Migration Issues for NFSv4              July 2004


5.2.  Referral Interactions (LOOKUP)

     The details of how referrals proceed are implicit in the
     specification of migration in RFC 3530.  However, because the
     details of handling of this case are so different from those in the
     cases discussed therein, examples tailored to the referral
     situation are needed to clarify matters and allow correct and
     consistent implementations.

     Let us suppose that the following COMPOUND is issued in an
     environment in which /src/linux/2.7/latest is absent from the
     target server.  This may be for a number of reasons.  It may be the
     case that the file system has moved, or, it may be the case that
     the target server is functioning mainly or solely to refer clients
     to the server on which the file system is located.

     o    PUTROOTFH

     o    LOOKUP "src"

     o    LOOKUP "linux"

     o    LOOKUP "2.7"

     o    LOOKUP "latest"

     o    GETFH

     o    GETATTR fsid,fileid,size,ctime

     Under the given circumstances, the following will be the result.

     o    PUTROOTFH  --> NFS_OK

          Current fh is root of pseudo-fs.

     o    LOOKUP "src" --> NFS_OK

          Current fh is for /src and is within pseudo-fs.

     o    LOOKUP "linux" --> NFS_OK

          Current fh is for /src/linux and is within pseudo-fs.

     o    LOOKUP "2.7" --> NFS_OK

          Current fh is for /src/linux/2.7 and is within pseudo-fs.




Noveck                    Expires January 2005                  [Page 8]


Internet-Draft         Migration Issues for NFSv4              July 2004


     o    LOOKUP "latest" --> NFS_OK

          Current fh is for /src/linux/2.7/latest and is within a new,
          absent fs, but ...

          The client will never see the value of that fh.

     o    GETFH --> NFS4ERR_MOVED

          Fails because current fh is in an absent fs at the start of
          the operation and the spec makes no exception for GETFH.

     o    GETATTR fsid,fileid,size,ctime

          Not executed because the failure of the GETFH stops processing
          of the COMPOUND.

     Given the failure of the GETFH, the client has the job of
     determining the root of the absent file system and where to find
     that file system, i.e. the server and path relative to that
     server's root fh.  Note here that in this example, the client did
     not obtain filehandles and attribute information (e.g. fsid) for
     the intermediate directories, so that he would not be sure where
     the absent file system starts.  It could be the case, for example,
     that /src/linux/2.7 is the root of the moved filesystem and that
     the reason that the lookup of "latest" succeeded is that the
     filesystem was not absent on that op but was moved between the last
     LOOKUP and the GETFH (since COMPOUND is not atomic).  Even if we
     had the fsid's for all of the intermediate directories, we could
     have no way of knowing that /src/linux/2.7/latest was the root of a
     new fs, since we don't yet have its fsid.

     In order to get the necessary information, let us re-issue the
     chain of lookup's with GETFH's and GETATTR's to at least get fsid's
     and fs_locations values.

     o    PUTROOTFH  --> NFS_OK

          Current fh is root of pseudo-fs.

     o    GETATTR(fsid)  --> NFS_OK

          Just for completeness.  Normally, clients will know the fsid
          of the pseudo-fs as soon as they establish communication with
          a server.

     o    LOOKUP "src" --> NFS_OK




Noveck                    Expires January 2005                  [Page 9]


Internet-Draft         Migration Issues for NFSv4              July 2004


     o    GETATTR(fsid, fs_locations)  --> NFS_OK

          Get current fsid to see where fs boundaries are.  The fsid
          will be that for the pseudo-fs in this example, so no
          boundary.  Get fs_locations just in case "src" is part of fs
          that moved.

     o    GETFH --> NFS_OK

          Current fh is for /src and is within pseudo-fs.

     o    LOOKUP "linux" --> NFS_OK

          Current fh is for /src/linux and is within pseudo-fs.

     o    GETATTR(fsid, fs_locations)  --> NFS_OK

          Get current fsid to see where fs boundaries are.  The fsid
          will be that for the pseudo-fs in this example, so no
          boundary.  Get fs_locations just in case "linux" is part of
          the fs that moved.

     o    GETFH --> NFS_OK

          Current fh is for /src/linux and is within pseudo-fs.

     o    LOOKUP "2.7" --> NFS_OK

          Current fh is for /src/linux/2.7 and is within pseudo-fs.

     o    GETATTR(fsid, fs_locations)  --> NFS_OK

          Get current fsid to see where fs boundaries are.  The fsid
          will be that for the pseudo-fs in this example, so no
          boundary.  Get fs_locations just in case "2.7" is part of fs
          that moved.

     o    GETFH --> NFS_OK

          Current fh is for /src/linux/2.7 and is within pseudo-fs.

     o    LOOKUP "latest" --> NFS_OK

          Current fh is for /src/linux/2.7/latest and is within a new,
          absent fs, but ...

          The client will never see the value of that fh




Noveck                    Expires January 2005                 [Page 10]


Internet-Draft         Migration Issues for NFSv4              July 2004


     o    GETATTR(fsid, fs_locations)  --> NFS_OK

          We are getting the fsid to know where the fs boundaries are.
          The server may oblige us by giving us an fsid value different
          from that of the pseudo-fs.  However, RFC 3530 does not oblige
          him to give us anything but fs_locations, so this may not be
          available.  Note that if we did have the fsid, it would not
          necessarily be preserved at the new location.  That fsid might
          be different and in fact the fsid we have for this fs might be
          the fsid of a different fs on that new server.

          In this particular case, we are pretty sure anyway that what
          has moved is /src/linux/2.7/latest rather than /src/linux/2.7
          since we have the fsid of the latter and it is that of the
          pseudo-fs, which presumably cannot move.  However, in other
          examples, we might not have this kind of information to rely
          on (e.g. /src/linux/2.7 might be a non-pseudo filesystem
          separate from /src/linux/2.7/latest), so we need to have
          another reliable source information on the boundary of the fs
          which is moved.

          The fs_locations attribute indicates the server and server-
          relative path of the fs's new location but it also gives us
          the necessary information about the fs boundaries via the
          fs_root field.  In this case the fs_root field is
          /src/lnux/2.7/latest, telling us where the moved fs starts.

     o    GETFH --> NFS4ERR_MOVED

          Fails because current fh is in an absent fs at the start of
          the operation and the spec makes no exception for GETFH.  Note
          that this has the happy consequence that we don't have to
          worry about the volatility or lack thereof of the fh.  If the
          root of the fs on the new location is a persistent fh, then we
          can assume that this fh, which we never saw is a persistent
          fh, which, if we could see it, would exactly match the new fh.
          At least, there is no evidence to disprove that.  On the other
          hand, if we find a volatile root at the new location, then the
          filehandle which we never saw must have been volatile or at
          least nobody can prove otherwise.

     Given the above, the client knows where the root of the absent file
     system is, either by noting where the change of fsid occurred, or,
     if that is not provided, by means of the fs_root field of the
     fs_locations attribute.  The fs_locations attribute also gives the
     client the actual location of the absent file system, so that the
     referral can proceed.  Generally, the server will give the client
     the bare minimum of information about the absent file system so



Noveck                    Expires January 2005                 [Page 11]


Internet-Draft         Migration Issues for NFSv4              July 2004


     that there will be very little scope for problems of conflict
     between information sent by the referring server and information of
     the file system's home.  No filehandles and very few attributes are
     present on the referring server and the client can treat those it
     receives as basically transient information with the function of
     enabling the referral.

5.3.  Referral Interactions (READDIR)

     Another context in which a client may encounter referrals is when
     it does a READDIR on directory in which some of the sub-directories
     are the roots of absent file systems.  In this case, NFS4ERR_MOVED
     is not an appropriate return because the directory in question is
     available and only the entries, whose attributes are being
     interrogated, are for absent file systems.

     The appropriate approach for the server in this case is to provide
     the attributes which it can provide and not provide those that
     require access to the actual file system, while allowing the client
     to deduce that an fs boundary is present and that the file system
     is absent.  Fortunately, this can be done fairly easily, as long as
     the client and server take proper care.

     The basic strategy is to return only the attributes that can
     validly be provided by the referring server.  Others are simply not
     provided.  The spec allows this to be done if the client requests
     the rdattr_error as part of the READDIR, so, if the client does not
     request this attribute routinely, it must do so when re-issuing a
     READDIR which gets an NFS4ERR_MOVED error.  Without a request for
     rdattr_error, NFS4ERR_MOVED could mean that the directory being
     read is within an absent file system or that one or more of the
     entries in the directory is the root of an absent file system.
     There is simply no way of determining which unless rdattr_error is
     requested.

     Assuming the rdattr_error is requested, the server should, for the
     roots of absent file systems, return the attributes listed below
     when they are requested and no others.  Returning other attributes
     may be possible in particular cases, but generally speaking, they
     are not necessary for clients to function and since clients will
     have to be prepared to get the necessary information from the
     actual root of the fs on the other server, servers are best advised
     to simply return this small set.

     o    fs_locations

          Location of the file system for the client's use when he needs
          to do the nested mount or to get attribute information about



Noveck                    Expires January 2005                 [Page 12]


Internet-Draft         Migration Issues for NFSv4              July 2004


          the root of the fs.

     o    fsid

          Needs to be a value different from the fsid of the containing
          directory, in order to indicate to the client that a file
          system boundary is present.

          Note that the client should not expect that the actual fs,
          when located, will have the same fsid. Fsid's are unique only
          within the set of file systems exported by a single server so
          it might be possible to maintain the fsid on a different
          server. In any case, a client will be capable of using file
          systems on multiple servers and will therefore, if it needs to
          present unique identifiers for file systems to present to
          applications, needs to create them and not assume that using
          fsid's will provide the requisite uniqueness. So a change of
          mapping from one fsid-server pair to a given id, to another
          fsid-server pair as part of a referral or migration should not
          pose difficulties.

     o    mounted_on_fileid

          The mounted_on_fileid attribute is of particular importance to
          many clients, in that they need this information to form a
          proper response to a readdir() call. When a readdir() call is
          done within UNIX, the d_ino field of each of the entries needs
          to have a unique value normally derived from the NFSv4 fileid
          attribute. It is in the case in which a file system boundary
          is crossed that using the fileid attribute, particularly when
          crossing into an absent fs, that use of the fileid attribute
          for this purpose will pose problems.  Note first that the
          fileid attribute, since it is within a new fs and thus a new
          fileid space, will not be unique within the directory. Also,
          since the fs, at its new location, may arrange things
          differently, the fileid decided on at the directing server may
          be overridden at the target server, making it of little value.
          Neither of these problems arise in the case of
          mounted_on_fileid since that fileid is in the context of the
          mounted-on fs and unique within it.

     o    rdattr_error

          The value should always be NFS4ERR_MOVED for entries that
          correspond to the root of absent file systems






Noveck                    Expires January 2005                 [Page 13]


Internet-Draft         Migration Issues for NFSv4              July 2004


5.4.  Editorial Changes Related to Referrals

     Given the above framework for implementing referrals, within the
     basic migration framework described in RFC 3530, we need to
     consider how future NFSv4 RFC's should be modified, relative to RFC
     3530, to address referrals.

     The most important change is to include an explanation of how
     referrals fit into the v4 migration model.  Since the existing
     discussion does not specifically call out the case in which the
     absence of a filesystem is noted while attempting to cross into the
     absent file system, it makes it hard to understand how referrals
     would work within the existing protocol.  This needs to be
     corrected to allow better understanding of the capabilities of
     NFSv4.0 which will be retained in future minor versions of NFSv4.
     It makes sense to present a description of referrals in a new sub-
     section following the "Migration" section, and would be section
     6.2.1, given the current numbering scheme of RFC 3530.  The
     material in the previous sub-sections of this document should be
     helpful in explaining the details of referral handling.

     There are also a number of cases in which the existing wording of
     RFC 3530 seems to ignore the referral case of the migration
     feature.  In the following specific cases, some suggestions are
     made for edits to tidy this up.

     o    In section 1.4.3.3, in the third sentence of the first
          paragraph, the phrase "In the event of a migration of a
          filesystem" is unnecessarily restrictive and having the
          sentence read "In the event of the absence of a filesystem,
          the client will receive an error when operating on the
          filesystem and it can then query the server as to the current
          location of the file system" would be better.

     o    In section 6.2, the following should be added as a new second
          paragraph: "Migration may be signaled when a file system is
          absent on a given server, when the file system in question has
          never actually been located on the server in question.  In
          such a case, the server acts to refer the client to the proper
          fs location, using fs_locations to indicate the server
          location, with the existence of the server as a migration
          source being purely conventional."

     o    In the existing second paragraph of section 6.2, the first
          sentence should be modified to read as follows: "Once a
          filesystem has been successfully established at a new server
          location, the error NFS4ERR_MOVED will be returned for
          subsequent requests received by the server whose role is as



Noveck                    Expires January 2005                 [Page 14]


Internet-Draft         Migration Issues for NFSv4              July 2004


          the source of the filesystem, whether the filesystem actually
          resided on that server, or whether its original location was
          purely nominal (i.e. the pure referral case)."

     o    The following should be added as an additional paragraph to
          the end of section 6.4, the: "Note that in the case of a
          referral, there is no issue of filehandle recovery since no
          filehandles for the absent filesystem are communicated to the
          client (and neither is the fh_expire_type)".

     o    The following should be added as an additional paragraph to
          the end of section 8.14.1: "Note that in the case of referral,
          there is no issue of state recovery since no state can have
          been generated for the absent filesystem."

     o    In section 12, in the description of NFS4ERR_MOVED, the first
          sentence should read, "The filesystem which contains the
          current filehandle object is now located on another server."

6.  Acknowledgements

     The author wishes to thank Neil Brown for his helpful comments.

7.  Normative References

     [RFC3530]
          S. Shepler, et. al., "NFS Version 4 Protocol", Standards Track
          RFC

Author's Address

     David Noveck
     Network Appliance, Inc.
     375 Totten Pond Road
     Waltham, MA 02451 USA

     Phone: +1 781 768 5347
     EMail: dnoveck@netapp.com


Full Copyright Statement

     Copyright (C) The Internet Society (2004).  This document is
     subject to the rights, licenses and restrictions contained in BCP
     78 and except as set forth therein, the authors retain all their
     rights.

     This document and the information contained herein are provided on



Noveck                    Expires January 2005                 [Page 15]


Internet-Draft         Migration Issues for NFSv4              July 2004


     an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
     THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
     THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
     ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
     PARTICULAR PURPOSE.

Intellectual Property

     The IETF takes no position regarding the validity or scope of any
     Intellectual Property Rights or other rights that might be claimed
     to pertain to the implementation or use of the technology described
     in this document or the extent to which any license under such
     rights might or might not be available; nor does it represent that
     it has made any independent effort to identify any such rights.
     Information on the procedures with respect to rights in RFC
     documents can be found in BCP 78 and BCP 79.

     Copies of IPR disclosures made to the IETF Secretariat and any
     assurances of licenses to be made available, or the result of an
     attempt made to obtain a general license or permission for the use
     of such proprietary rights by implementers or users of this
     specification can be obtained from the IETF on-line IPR repository
     at http://www.ietf.org/ipr.

     The IETF invites any interested party to bring to its attention any
     copyrights, patents or patent applications, or other proprietary
     rights that may cover technology that may be required to implement
     this standard.  Please address the information to the IETF at ietf-
     ipr@ietf.org.


Acknowledgement

     Funding for the RFC Editor function is currently provided by the
     Internet Society.














Noveck                    Expires January 2005                 [Page 16]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/