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:     Trond Myklebust <trondmy@hammerspace.com>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Olga Kornievskaia <aglo@umich.edu>
Subject: Re: client's caching of server-side capabilities
Thread-Topic: client's caching of server-side capabilities
Thread-Index: AQHXbFuOOfOdlv3jtEGkiccADhbLQKsp+uwAgAD5LQA=
Date:   Tue, 29 Jun 2021 12:58:08 +0000
Message-ID: <B0CA736F-E3E8-4446-9A6E-3ADCDD7F8736@oracle.com>
References: <CAN-5tyEuB5C9u+xZ5L47fSQ9cwZnsbhJuBs+gybU2A-jzAkfog@mail.gmail.com>
 <81154dc28d528402bf5e090a81e6892c7abc431c.camel@hammerspace.com>
In-Reply-To: <81154dc28d528402bf5e090a81e6892c7abc431c.camel@hammerspace.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?aZB1uNFSmM0J1ISYLZo2ZxhSH/PNVqS/SA6C99j1kfQBYMzCnRlxjHhcKQ37?=
 =?us-ascii?Q?ouc3OQsx0pLSbjHa/IVXJJuXkaYgjYHT3Mfbixdxi5Xo9AYaUDskUsuZP2Ls?=
 =?us-ascii?Q?rpZGai5eh0Ehj7jQwFN6C68TtkkcQsT8/tiunomMh28mr7aAEVY3qm1QEhUl?=
 =?us-ascii?Q?t4LjkSsdK1mxwPJ3pk1bLn15ZMr3HDmSW87+kUSl3BBrr2ln1FsHywMCaNHp?=
 =?us-ascii?Q?c58QWpaJQVJOZSfBC8dOOFTvPtBL2Q5CWL8xw+32SOQzZsEBUumQrc8Cdrro?=
 =?us-ascii?Q?+iQqL7JWvDI9huUP0ftNuFRqsfXfZwj1TGT9q3n52bH9a/bKwmrEvp/nIr7z?=
 =?us-ascii?Q?zTU+Nfd+MfNPbduGQR1oczI1jusQiazMFbZ/rfvQZ6Xnv8QfWjACyhGiJKH5?=
 =?us-ascii?Q?GSdIFqs6uoEsAevAFguvkBL/TLgb+6X2+t1arMdSFB3819G/qVDxW2udVUQZ?=
 =?us-ascii?Q?bwFusBPulEkkvCCGZDyeNNyctW3RE6BeJYChU1MulkWvyEtoGH4cLKKRt4YA?=
 =?us-ascii?Q?q8Me9JEucuS3X5GyEw/+qnX4hLriAOovRNE0XwWwxypha7A2jujgri2stSJ4?=
 =?us-ascii?Q?IWxO4pjoSxxK0xPY7FUEwZ+3rtSTWjfRZitQe1qnR0jj+ODsAQB0H0KKG2iw?=
 =?us-ascii?Q?bJVLz5mTdHWojbQOyqu2WLc7gyKWRrt6haCfCdK/RuquYzgokMv7wkI4RdPj?=
 =?us-ascii?Q?mQs2lRRyw5sLalgVxfzmykanF5ckWFsFXO6XAB2C9h91xgO3roND82xtaLhl?=
 =?us-ascii?Q?T+YHGFKANAhcHlZ1VVAS0mRu2JA3tgMbsokDVO6eaz9OeXbpoa5SfEsu26jB?=
 =?us-ascii?Q?BRE9P6O76ZNYNn8WVNLYOyhGYmSK3JyfuZDSstLkrAAbinWtCzI/S0M8IQbX?=
 =?us-ascii?Q?UC1le4y2wTVI/S4KiVtBMcwSx/masnXch9v5DbTejnVBvQ0ieTzqv6m8yfLW?=
 =?us-ascii?Q?y+oBV9Th1jjkMWPClegd/ULRJbYSZIA2rFVVAFMy3KA/YlOZisNYEkhRd+85?=
 =?us-ascii?Q?2EQ7Uh4tYmLu0htDTn2vjUMmZB+dJC62ZxA/3OSZqVsLRQvubvKlZNjMIPEC?=
 =?us-ascii?Q?5K4yxn9GRujbpI9lp5ThIg4S4YjrA1nP6IR/lC8l4b1NHqtfCszWGmgVDqtJ?=
 =?us-ascii?Q?36hytB03SmLvF6NqofpCZGnA/w6+VAHnysjPezM016MuWZzqGbn010ggBv3T?=
 =?us-ascii?Q?1/jrfGBZJorCCxDZiF3kuJdWwdSx4seod0m7LHSyPFcIiHK3gXXc/eXyDhm9?=
 =?us-ascii?Q?iPvUqflGxHJM+YcrSBaGCQ1AT1pYQV5DUQi//6jcF2FQCilatbYlvnibA5gU?=
 =?us-ascii?Q?Jp6QlJaMQKX7o2hGRX0UQXJi?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3C2D6080AD810A4B93F27B28EAC7C86E@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: fb43947d-4817-4b4a-2a5f-08d93afd8b2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2021 12:58:08.4599
 (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: pxV5uMBOGoDxatzNlWQesCK93gH49GfEAcyRNjCGvuQ94Z51Uf7/F4FwlTmdDNToJcG3jNedBF7xpxvdtewLhw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB5408
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10029 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0
 mlxlogscore=999 phishscore=0 spamscore=0 malwarescore=0 mlxscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2104190000 definitions=main-2106290087
X-Proofpoint-GUID: 75Ux02YGuB3W3dDj-WDZnz_ekUFd2ngD
X-Proofpoint-ORIG-GUID: 75Ux02YGuB3W3dDj-WDZnz_ekUFd2ngD
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Jun 28, 2021, at 6:06 PM, Trond Myklebust <trondmy@hammerspace.com> wr=
ote:
>=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.

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.


--
Chuck Lever