On Fri, Aug 05, 2011 at 09:38:33AM -0400, Christoph Hellwig wrote: > On Thu, Aug 04, 2011 at 12:03:44PM -0400, J. Bruce Fields wrote: > > The client has no way of knowing that an export is read only. (Or that > > the server guarantees the safety of looking up names again in the more > > general cases Neil describes.) Unless we decide that a server is making > > an implicit guarantee of that just by exposing volatile filehandles at > > all. Doesn't sound like the existing spec really says that, though. > > > > If an examination of existing implementations and/or some sort of new > > spec language could reassure us that servers will only ever expose > > volatile filehandles when it's safe to do so, then maybe it would make > > sense for the client to implement volatile filehandle recovery? > > > > But if there's a chance of "unsafe" servers out there, then it would > > seem like a trap for the unwary user.... > > > > Your rootfs's probably aren't terribly large--could you copy around > > compressed block-level images instead of doing rsync? > > Another scheme is to disconnect the file handles from the inode number. > I implemented this a couple years ago for a customer. Basically add > an extended attribute into each inode that contains the nfs file handle, > and that handle stays the same independent of the inode number. The > added complexity is that you need a new lookup data structure mapping And that data structure should be persistent--how were you storing it? > from your nfs handle to something that can be used to find the inode > (inode number typically). Interesting, I've wondered before how well that would work. Any lessons learned? --b. -- 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
