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;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Olga Kornievskaia <aglo@umich.edu>
CC:     Trond Myklebust <trondmy@hammerspace.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: client's caching of server-side capabilities
Thread-Topic: client's caching of server-side capabilities
Thread-Index: AQHXbFuOOfOdlv3jtEGkiccADhbLQKsp+uwAgAD5LQCAAA38gIAAAPwA
Date:   Tue, 29 Jun 2021 13:51:43 +0000
Message-ID: <607F15BF-89B4-4123-8223-A3893229D219@oracle.com>
References: <CAN-5tyEuB5C9u+xZ5L47fSQ9cwZnsbhJuBs+gybU2A-jzAkfog@mail.gmail.com>
 <81154dc28d528402bf5e090a81e6892c7abc431c.camel@hammerspace.com>
 <B0CA736F-E3E8-4446-9A6E-3ADCDD7F8736@oracle.com>
 <CAN-5tyE5Y3+ZPrfAR8=UVdNnWxyzO6a_NTeTsMFH_TyyMqK-bQ@mail.gmail.com>
In-Reply-To: <CAN-5tyE5Y3+ZPrfAR8=UVdNnWxyzO6a_NTeTsMFH_TyyMqK-bQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?zfW9tSeoIEe3CVcfBAd3rUigtwA1fKsusn02zHFg9Axixx73VWBylmIRvSQq?=
 =?us-ascii?Q?Cx8YVrWtsiQFcAopBMLtEX0b4MkT2j6NlftrR790GHxtmkuCPsbWrKZx8RwT?=
 =?us-ascii?Q?ce0rNMwcZNVLbvqvE44/akN9n7I3TIDlGIGLvOfTcppGhJNCVS+E3XAW8DwY?=
 =?us-ascii?Q?ul/5sZqmPfMvM66iRNP+7zBA4KHsERCHJjF74F3JmspBfeT8gAKe4L/dLjZ7?=
 =?us-ascii?Q?FET+icjOYXz6TuERyIfe19JsUa8pMctiVzypSkN1v0bmySYSFqqBmYs1ay7G?=
 =?us-ascii?Q?MUW5GwLY+Am+DucwwypQMt8hlgAO3FyySJQ3ye2n6xyA3FJpDBHsyRMV/jiQ?=
 =?us-ascii?Q?IwGHhM8w8zzkD2PEbgSpBtZo/psK89ZfTqidM9olnZgoLNL1BvrHHlxztnUj?=
 =?us-ascii?Q?r3+GcI1gzJZ2W+pIhi+OMpFsBDKstjg2/HDKZquQrVA18HeCmBjtTvFTY5jc?=
 =?us-ascii?Q?dNwL1njDJHPqMykkH0vVv0nZzxo69CdDYycwMYOHN2hi7MLIQOU4QL6Jydoy?=
 =?us-ascii?Q?0QC7joGHeYWLOT2/Rs2IT4UiEvXxLGyX77JAVkMlaxWsXP73ttWv/iRJRcKl?=
 =?us-ascii?Q?OKow528OJbcfyWzuG4SUDbtlYdjQ9TlM7o2Ajcu1474l2Wbwp352enwexDBx?=
 =?us-ascii?Q?N6UrDAi87jD3EYDdoUmZ43Bz7p6eB7DcgkhM7NQlNTAq08Q60YPYxLhTloWs?=
 =?us-ascii?Q?/iY0htAcQXOlVX3uaMgcfZBUPz54CGihAH10Fh44ql4IWiC1ct9zaZt/sIYL?=
 =?us-ascii?Q?NxZ6KdgljRKWW5NWVdMuSuC/ro3L9KnVJG+5trEBcx34XVJ3+R3nP6mSjpB+?=
 =?us-ascii?Q?evMKFyFnblFtklEO0Kz5kC7KkIAk0Nrr6ca0VjSL93REGruFTZ2rXzd2EqNO?=
 =?us-ascii?Q?+PSWRJ+jQqpP9ToNnWWSG2Uk9wFtF6hAl90aUqRHvHpJqbJkYwoLtkt/Qe7L?=
 =?us-ascii?Q?mM0aOEu+C/94e6sRUbxiwSh5RDpqbdNi7HwzH/jHDkD42K10j4257F6nJElb?=
 =?us-ascii?Q?Z7bTHUxF78gqCYeKX8bfpWKRnIR0KOolnfHkGsB1GNDUH7Ko1yO2xjR0oiPV?=
 =?us-ascii?Q?htsPH0gCBO7qKuC51R9S7KXdfoWqB4LfqTy1EJagR3VUWFhohDSynZl4JZwS?=
 =?us-ascii?Q?H8AgwwMBjNo3cQEwvu69yNaqDTzP6dhhKncWiiPsq6JbrHqZDuPp4tLVFL9x?=
 =?us-ascii?Q?yuAyczuyDjU0eiNOt1qya1Jli2tRE/z5drqix3O9WksiYYvEpQrC/fq6mCss?=
 =?us-ascii?Q?nL4ljhV2qK6nLNnCCjdQjSX+oNZ+Msqna7N1ozIfq5XRD8s5OaS9F6sS3lYL?=
 =?us-ascii?Q?KQqZU2g9ICSFs6OM4YsgMZxk?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15F4BA8DDF6A8D48847BFAFB66F50230@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB4688.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b89eedd-ddd9-44bf-722b-08d93b0507bc
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2021 13:51:43.9435
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: p/eZWHdZiW8jUIsvPmITLrYn2vsEh7k7tH+ypRObXt2XsSGwP3yipDnJLYMheSILzyDpM6q4OVhaA3KXip0dgg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR10MB4147
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10029 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 adultscore=0
 malwarescore=0 mlxlogscore=999 suspectscore=0 phishscore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000
 definitions=main-2106290093
X-Proofpoint-GUID: hJwSm_klAlHL3NaSvkP5F1bvVPiF3n2Y
X-Proofpoint-ORIG-GUID: hJwSm_klAlHL3NaSvkP5F1bvVPiF3n2Y
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Jun 29, 2021, at 9:48 AM, Olga Kornievskaia <aglo@umich.edu> wrote:
>=20
> On Tue, Jun 29, 2021 at 8:58 AM Chuck Lever III <chuck.lever@oracle.com> =
wrote:
>>=20
>>=20
>>=20
>>> On Jun 28, 2021, at 6:06 PM, Trond Myklebust <trondmy@hammerspace.com> =
wrote:
>>>=20
>>> On Mon, 2021-06-28 at 16:23 -0400, Olga Kornievskaia wrote:
>>>> Hi folks,
>>>>=20
>>>> 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).
>>>>=20
>>>> 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?
>>>>=20
>>>> Thank you.
>>>=20
>>> 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.
>>=20
>> I 100% agree with the above. However...
>>=20
>>=20
>>> Detection of new features, etc
>>> can wait until the client needs to restart.
>>=20
>> 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.
>=20
> Can you clarify what you mean by a "failover to a different server"?

IP-based failover means that a server can crash, and its partner can
detect that and take over the IP address and exports of the failed
server. The replacement server doesn't have to have exactly the same
set of capabilities.


> 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?
>=20
> Thank you for the feedback!
>=20
>>=20
>>=20
>> --
>> Chuck Lever

--
Chuck Lever