On Wed, 2011-08-03 at 18:16 -0700, Malahal Naineni wrote: > NeilBrown [neilb@xxxxxxx] wrote: > > > > I substantially agree, though I think the implication can be refined a > > little. > > > > I would say that the implication is that a VFH is only really usable > > when the complete path leading to the file in question is read-only. > > We don't need to assume that other files in other parts of the > > hierarchy which have stable file handles are read-only. > > > > So if the server presents us with a VFH, it seems reasonable to assume > > that we can use a repeated lookup of the same name to refresh the > > filehandle simply because there is no other credible way to respond to > > a FHEXPIRED. > > The spec seems to imply that repeated lookup of the same name to refresh > the file handle is OK as long as the file is OPEN! It doesn't seem to imply > anything for files that are not opened. I see no such implication for a migration situation, unless you also migrate the open state. Even if you do, then you still have to somehow recover directory filehandles for the current directory and any other RPC call that happened to be in progress when the original server was migrated. > "RFC 3530, 4.2.3. Volatile Filehandle" states: > > "Servers which provide volatile filehandles that may expire while open > (i.e., if FH4_VOL_MIGRATION or FH4_VOL_RENAME is set or if > FH4_VOLATILE_ANY is set and FH4_NOEXPIRE_WITH_OPEN not set), should deny > a RENAME or REMOVE that would affect an OPEN file of any of the > components leading to the OPEN file. In addition, the server should > deny all RENAME or REMOVE requests during the grace period upon server > restart." > > On the other hand, if FH4_NOEXPIRE_WITH_OPEN is set, then the file can > be allowed to be renamed or removed by the server. Which completely violates the expectations of POSIX applications on the client. Any idea how you would work around the above? Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
