Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Bruce Fields <bfields@fieldses.org>
CC:     Dai Ngo <dai.ngo@oracle.com>, Jeff Layton <jlayton@redhat.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH RFC v12 3/3] nfsd: Initial implementation of NFSv4
 Courteous Server
Thread-Topic: [PATCH RFC v12 3/3] nfsd: Initial implementation of NFSv4
 Courteous Server
Thread-Index: AQHYHjn74pyZfV9hjE2Fdxx9lh+2gqyM5lKAgAAUwICAAAWVAIAAI5yAgAABQIA=
Date:   Thu, 10 Feb 2022 19:04:09 +0000
Message-ID: <B3812DDF-AC10-4FCA-9380-2E98F5FE773E@oracle.com>
References: <1644468729-30383-1-git-send-email-dai.ngo@oracle.com>
 <1644468729-30383-4-git-send-email-dai.ngo@oracle.com>
 <20220210151759.GE21434@fieldses.org> <20220210163215.GH21434@fieldses.org>
 <2223051F-B8F5-4E59-8A27-735F6A426785@oracle.com>
 <20220210185941.GA24538@fieldses.org>
In-Reply-To: <20220210185941.GA24538@fieldses.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Vt+UqnO/Z7AFcA31uK/HT4z43UX2xITqtM0sniii+crehoh9MU50dwvWESft?=
 =?us-ascii?Q?GMXxjFvE3rjmQ+IFqwgWdSi4GSGaFDt1tym5RDyDe4IJV/bG09rNFtrgcpRr?=
 =?us-ascii?Q?jg5yiOm8KTagZXa6pUzUsuwijx+tbPEpnB1IvQm4eAszPV5N5B2Ct6SL40pZ?=
 =?us-ascii?Q?C7dgjztj7WSLZlva9WoZZdQBZMswf25vof2JeLGK2LdWUc2wqWprLO6Dv0R3?=
 =?us-ascii?Q?Sxyi1Z/0AeoxYxWQ27tCZeqA6jYksywsfEUW/opPDLnVHYjOgI3fiZ/2oaFn?=
 =?us-ascii?Q?BmXoiewatOZbAII8pNrnKyGmhIRSlXliOp3xCoLvktaPa+NPlqQ8XwN5urZf?=
 =?us-ascii?Q?c5jzix5a1BrAfszqY6Aktib7FnFofTb4CamD3zEU4ao5nNeFNkF8T3aCb8PB?=
 =?us-ascii?Q?zXtZMj4eUiaL8I+DtfhD5ypBC/aX2i427aqLTXrLn7iQMHUrcG/dNw9WVDmY?=
 =?us-ascii?Q?PQBLxtEbuhb+AhAjvfipHdXUMYTXrMDMbmE7E+5IV6CNA2yNgtOSBgYCZNEP?=
 =?us-ascii?Q?sf9BvvUEYYAJY8MJeV7ikstBZ2kyFeKsOBhUhfCavY2db+BCHbEVFqKKDicl?=
 =?us-ascii?Q?uXfa8N489OdbbXUANqAwRcgxByKgAF+O8bd030x1sf7teXuEtwLXBHOeQU3R?=
 =?us-ascii?Q?5xSeyEbWLrTox1Yw5JPU4RNUiAo8dbEgFtV6+O0NhMslIzSSmFNEMDQegSV/?=
 =?us-ascii?Q?PZrVWaBbiea6T/JpJS+Z63E/K0X/4nczms97wRfGk0sC7Zhfz8yKYKF0ExDU?=
 =?us-ascii?Q?iURE84FmJODUXWzMDDJAO9aQ+XPL+/HU7Riyl8YtKiddlHAy68Awxhl8EuTW?=
 =?us-ascii?Q?QLP/0W3MAuJVllmVh0BcFldu9CgYB3dzzUTXXmjpMUYf85B4JMFPd3KbfmKw?=
 =?us-ascii?Q?f5sF9aMwVU7D8qPzkRkBGU8PjpS3aRZKe74RKEtKJpXJ6ys1QjJmuwnFgZpU?=
 =?us-ascii?Q?KrxOHSNxHBmvgDGzevuYYnb0VxDxXfyjTS+ofiZML7yUDsRa0zxGGXQREw4V?=
 =?us-ascii?Q?4Hkb9h/lm5vpazZR0AOoS1nIFZ9vmyF50vGWxze1JPRPnISJ/qFY+4Pjkhrr?=
 =?us-ascii?Q?EZIst3Dl6ZCakC3ke1EKfYHnOj0pRDubVioOIOyG6OsXF6hop/lliRTDq2D8?=
 =?us-ascii?Q?Ce5Qbk6yJ6kMbssmULTZCLAFZGRTLln0sihwbHulLne3L4QB3CHcK0g83wrJ?=
 =?us-ascii?Q?MvO8R8w+iA8v97Bm8MihL3/FBrQ372k3YBGoy4Hi/PMCFcJVITu7d4TsNcn1?=
 =?us-ascii?Q?L0qNSRyE79y26rVqqxrN3WcQ3qVX3x9bYXbOS0NGVkOXcwwhRVjjPst3d5Lx?=
 =?us-ascii?Q?gCPhkAdkrluFITNFldGKTzEn6vdFzRp0unpmSh6AR2A/rjjcQTHV0iuqFVrb?=
 =?us-ascii?Q?QIAP5HAFW9HWWar234uNqwyRuaE4dttn/30AD4bgGmsFv/vh5ATuX6LUjATo?=
 =?us-ascii?Q?DGgEoHcZhLU76/9MLgGybeI1y2NhVvfKpvBHF3q57Pr4foWYSJxurKfqXrGP?=
 =?us-ascii?Q?HOwjK3ubQGHa7arWRRQj/P+GlENk9XvoaC1XfoWt71FlXprXrsFmYRANn89R?=
 =?us-ascii?Q?R7kJh5o/iJOj6TnjfP3GQalNQJswW81YwXzIAE61P6kwovkBHw0Y56iP+7fz?=
 =?us-ascii?Q?aDWvI2WuIoI14J8itwLEC9U=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C9DE8BA40CAB7F43A9C1960DD6F43529@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: CH0PR10MB4858.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ce86ffe9-853a-4a2e-e75d-08d9ecc81e91
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2022 19:04:09.9035
 (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: NoMr/uR85upau27MGF5/uFPz1HpCGmI8BIx47BdedPiHmVUbr1jTgefeoc5U2cHQPU9GIGqcOXvKmpMsDdI2RA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB2598
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10254 signatures=673431
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 phishscore=0
 suspectscore=0 adultscore=0 malwarescore=0 bulkscore=0 spamscore=0
 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2201110000 definitions=main-2202100100
X-Proofpoint-GUID: jQTeE2fggXPyILBup7JYvJBqVrqAzQmw
X-Proofpoint-ORIG-GUID: jQTeE2fggXPyILBup7JYvJBqVrqAzQmw
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Feb 10, 2022, at 1:59 PM, Bruce Fields <bfields@fieldses.org> wrote:
>=20
> On Thu, Feb 10, 2022 at 04:52:15PM +0000, Chuck Lever III wrote:
>>=20
>>> On Feb 10, 2022, at 11:32 AM, J. Bruce Fields <bfields@fieldses.org> wr=
ote:
>>>=20
>>> I was standing in the shower thinking....
>>>=20
>>> We're now removing the persistent client record early, after the first
>>> lease period expires, instead of waiting till the first lock conflict.
>>>=20
>>> That simplifies conflict handling.
>>>=20
>>> It also means that all clients lose their locks any time a crash or
>>> reboot is preceded by a network partition of longer than a lease period=
.
>>>=20
>>> Which is what happens currently, so it's no regression.
>>>=20
>>> Still, I think it will be a common case that it would be nice to handle=
:
>>> there's a network problem, and as a later consequence of the problem or
>>> perhaps a part of addressing it, the server gets rebooted.  There's no
>>> real reason to prevent clients recovering in that case.
>>>=20
>>> Seems likely enough that it would be worth a little extra complexity in
>>> the code that handles conflicts.
>>>=20
>>> So I'm no longer convinced that it's a good tradeoff to remove the
>>> persistent client record early.
>>=20
>> Would it be OK if we make this change after the current work is merged?
>=20
> Your choice!  I don't have a strong opinion.

I don't disagree that a good quality server implementation should
handle the post-server-reboot case a little nicer. I would like to
avoid losing momentum on the current patch set, though.

Support for post-server-reboot courtesy can be phase 1.5.


--
Chuck Lever