Re: [PATCH 5/5] NFS: Save FSID's root FH in nfs_server

[Chuck Lever <chuck.lever@oracle.com>]

On Jun 25, 2013, at 5:15 PM, "Myklebust, Trond" <Trond.Myklebust@netapp.com> 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@netapp.com> 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