On Jun 25, 2013, at 5:15 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > 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? That's the way the APIs happen to be architected. I wasn't certain that exception->inode in nfs4_handle_exception(), and state->inode in nfs4_async_handle_error(), would always be non-NULL when I needed an inode pointer. > 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. It's quite convenient to always use the FSID's root FH, but I agree, it's not required by the protocol. Re: LEASE_MOVED, I'm not confident the client stops sending RENEW operations when it has no more open state. > 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. Alternately, we could save a pointer to the FSID's root dentry or inode. -- Chuck Lever chuck[dot]lever[at]oracle[dot]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
