On Mon, Nov 14, 2011 at 10:09:58AM +0100, Tigran Mkrtchyan wrote: > > The other thought was that this could be used for migration/replication > > between file synced servers. So, if we wanted to switch/move to another server where > > the file names were the same but all the inode numbers were different you could use > > this to refresh the invalid file handles on the new server. > > If my scec reading is correct, then spec does not enforce you to use > the same file handles on redirected server. This is of course you you > want to return NFS4ERR_MOVED. What I was referring to was Section 6.4: Filehandles for filesystems that are replicated or migrated generally have the same semantics as for filesystems that are not replicated or migrated. For example, if a filesystem has persistent filehandles and it is migrated to another server, the filehandle values for the filesystem will be valid at the new server. So in the case where you sync the files between 2 servers using some type of file transfer (for example, rsync) the file handles will be different because all the inode numbers would be different between the machines. You can use VFH to get around this though, the same section states: If the bit FH4_VOL_MIGRATION is set in the fh_expire_type attribute, the client must treat the volatile filehandle as if the server had returned the NFS4ERR_FHEXPIRED error. At the migration or replication event in the presence of the FH4_VOL_MIGRATION bit, the client will not present the original or old volatile filehandle to the new server. The client will start its communication with the new server by recovering its filehandles using the saved file names. So assuming you synced the files so that the paths are the same on the 2 servers, by having the servers just return FH4_VOL_MIGRATION for FH_EXPIRE_TYPE, you could then use VFH recovery to lookup the current file handles for the new server. -Matt Treinish -- 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
