On Mon, 2011-08-15 at 13:49 -0700, Malahal Naineni wrote: > NeilBrown [neilb@xxxxxxx] wrote: > > > POSIX allows the namespace to change at any time (rename() or unlink()) > > > and so you cannot rely on addressing files by pathname. That was the > > > whole reason for introducing filehandles into NFSv2 in the first place. > > > > > > Volatile filehandles were introduced in NFSv4 without any attempt to fix > > > those shortcomings. There is no real prescription for how to recover in > > > a situation where a rename or unlink has occurred prior to the > > > filehandle expiring. Nor is there a reliable prescription for dealing > > > with the case where a new file of the same name has replaced the > > > original. > > > Basically, the implication is that volatile filehandles are only really > > > usable in a situation where the whole Filesystem is read-only on the > > > server. > > > > 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. > > The spec recommends "change" attribute for validating data cache, name > cache, etc. Some client implementations use "change" attribute for > validating VFH though! Can we use it for validating VFH? The change attribute can only be used as a heuristic since it is not guaranteed to be a value that is unique to one file. 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
