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 from your nfs handle to something that can be used to find the inode (inode number typically). -- 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
