On Tue, 2013-06-25 at 13:22 -0700, Chuck Lever wrote: > On Jun 25, 2013, at 12:37 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > > > On Tue, 2013-06-25 at 12:24 -0400, Chuck Lever wrote: > >> Save each FSID's root file handle in the FSID's nfs_server structure > >> on the client. This is needed for NFSv4 migration recovery. > > > > Please just use sb->s_root. > > The migration recovery procedures do not take an inode or dentry argument. All we have is an nfs_server. I see > > struct nfs_server *server = NFS_SB(sb); > > but what is the preferred method for going the other way? A naive approach would be to plant a super_block back-pointer in each nfs_server. Why do you not have an inode or dentry? Surely the migration must have been triggered either by an operation involving a filehandle, in which case you have an inode, or by a LEASE_MOVED, in which case there is open state on the target filesystem. I'm not opposed to putting a backpointer to the super_block in the nfs_server, but I do want to understand why it is needed. -- 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
