This interface will not return a volatile file handle, period, ever. Nicolas Williams wrote: > On Fri, Aug 28, 2009 at 04:07:03PM -0500, Rich.Brown at Sun.COM wrote: >> However, having nfs4_fid() return a file id can be useful in a very >> narrow, controlled context. This file ID can be used as an opaque >> cookie which can be compared to file IDs from other vnodes from the >> same vfs. This could be used by a file tree walking program to >> determine if a newly looked up file had been discovered previously >> since, by definition, the file handle uniquely identifies a different >> file in the protocol. This ID is persistent (assuming the server is >> using persistent file handles) and is therefore durable and reliable > > That's a big assumption. There was a thread recently on nfs-discuss > about adding server support for volatile file handles, for use with FUSE > filesystems that lack persistent file IDs. I think that would be very > useful. But even beyond that, volatile filehandles are in there to help > cope with filesystems such as FAT, where no persistent file IDs exist, > and so existing servers may very well be using volatile filehandles. > >> across reboots of both the client and server. The consumer of this ID >> can write it to stable storage and safely recover its state even after >> a client reboot. > > Doesn't sound right to me. But then, this: > >> Therefore, nfs4_fid() is reimplemented to return the client file handle >> from the rnode as a file ID, solely for the purpose of doing this >> equivalency comparison. nfs4_vget() will not honor this file ID, >> meaning that it can ONLY be used in this manner, it cannot be used to >> activate a vnode. > > limits the damage that one could do by persistently storing volatile > FIDs. > >> Since this new behavior may expose existing subsystems, like cachefs, >> to new failure modes, nfs4_fid() will only return a file ID when the >> client file system is mounted with "-o fid". By default, the option is >> off and the NFSv4 client will retain its current behavior. >> >> Ideally, this mount option is only used by system components which wish >> to use the file ID for identification as described above. Other uses >> are not supported. The option will NOT be documented, due to its >> limited utility. > > It might be better if there was a way for the VOP to indicate that the > returned FID is volatile. Maybe a pathconf that looks at the > per-filesystem fh_expire_type attribute? > > Nico
-- Bill Baker, 512-401-1081, x64081
