Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAN-5tyEuB5C9u+xZ5L47fSQ9cwZnsbhJuBs+gybU2A-jzAkfog@mail.gmail.com>
 <81154dc28d528402bf5e090a81e6892c7abc431c.camel@hammerspace.com> <B0CA736F-E3E8-4446-9A6E-3ADCDD7F8736@oracle.com>
In-Reply-To: <B0CA736F-E3E8-4446-9A6E-3ADCDD7F8736@oracle.com>
From:   Olga Kornievskaia <aglo@umich.edu>
Date:   Tue, 29 Jun 2021 09:48:11 -0400
Message-ID: <CAN-5tyE5Y3+ZPrfAR8=UVdNnWxyzO6a_NTeTsMFH_TyyMqK-bQ@mail.gmail.com>
Subject: Re: client's caching of server-side capabilities
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     Trond Myklebust <trondmy@hammerspace.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Jun 29, 2021 at 8:58 AM Chuck Lever III <chuck.lever@oracle.com> wrote:
>
>
>
> > On Jun 28, 2021, at 6:06 PM, Trond Myklebust <trondmy@hammerspace.com> wrote:
> >
> > On Mon, 2021-06-28 at 16:23 -0400, Olga Kornievskaia wrote:
> >> Hi folks,
> >>
> >> I have a general question of why the client doesn't throw away the
> >> cached server's capabilities on server reboot. Say a client mounted a
> >> server when the server didn't support security_labels, then the
> >> server
> >> was rebooted and support was enabled. Client re-establishes its
> >> clientid/session, recovers state, but assumes all the old
> >> capabilities
> >> apply. A remount is required to clear old/find new capabilities. The
> >> opposite is true that a capability could be removed (but I'm assuming
> >> that's a less practical example).
> >>
> >> I'm curious what are the problems of clearing server capabilities and
> >> rediscovering them on reboot? Is it because a local filesystem could
> >> never have its attributes changed and thus a network file system
> >> can't
> >> either?
> >>
> >> Thank you.
> >
> > In my opinion, the client should aim for the absolute minimum overhead
> > on a server reboot. The goal should be to recover state and get I/O
> > started again as quickly as possible.
>
> I 100% agree with the above. However...
>
>
> > Detection of new features, etc
> > can wait until the client needs to restart.
>
> A server reboot can be part of a failover to a different server. I
> think capability discovery needs to happen as part of server reboot
> recovery, it can't be optimized away.

Can you clarify what you mean by a "failover to a different server"?
To do reboot recovery it has to be the "same" server (by the
definitions of the RFC). My use case I was thinking of was a reboot of
the "same" server (major, minor, scope same) but with new features but
of course one could argue if it has new features it's no longer the
"same" server. I think you are probably thinking about migration or
are you thinking of telling a difference between session trunkable
servers which are considered to be the same but since it's a different
IP it might have different capabilities?

Thank you for the feedback!

>
>
> --
> Chuck Lever
>
>
>