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:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Cache flush on file lock
Thread-Topic: Cache flush on file lock
Thread-Index: AQHYF9ij5r5wZxOe10G+VO/hoTSM1KyArgyAgAM1aICABJlgAA==
Date:   Mon, 7 Feb 2022 19:09:42 +0000
Message-ID: <BAA6F711-7291-4EE2-B45C-C25ABC051D18@oracle.com>
References: <20220202014111.GA7467@hostway.ca>
 <4691F0AB-FCDB-49EF-B62B-51F135F692A5@oracle.com>
 <309e27b9-da26-bcd0-dc55-1b63cb93203f@math.utexas.edu>
In-Reply-To: <309e27b9-da26-bcd0-dc55-1b63cb93203f@math.utexas.edu>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?XgsQSUQ8lWt1vF36oryO6sSOOtp5ccgfpKoO6S6XYPXaRQce5d0+2F4OrWFK?=
 =?us-ascii?Q?FSqVB5fKd4UHzbgNuohRxYJ1KwzNBMvkV9JHgkdion3WtekzeC0WyEoN+o5/?=
 =?us-ascii?Q?FTElgOx2m5XCHZ+9gFu+h3ypFqLJyXCNJPfYX1+nBgHM8TYpaoIHs4c3RVSQ?=
 =?us-ascii?Q?rpf4SZ94mWlGWW7GsSPX4UidS6px2ypV3ls6rVOriS30pqqOIpqxmkL1gvtv?=
 =?us-ascii?Q?VzHI52twuZCDIjAc9ZeY0zzAWZVfKI8B9LsCYjkVOAxTCEb0n5HfjNrre+a0?=
 =?us-ascii?Q?z9UG8+eNRYNTnlpID9BqlB4SSLN0use39p030tq5bUcZCdNhNApkmcgcInNe?=
 =?us-ascii?Q?NjakTyUs325mAgWIv56z88pnVaro/DfK6WNzSSbVnHBGYtN1ZOpbD8U8IhPg?=
 =?us-ascii?Q?7w8m954GjbZRp8iBUsmNg2bZlk3cKS9IVBqO2St5BLF8FTq4UqYECkR74a9I?=
 =?us-ascii?Q?r/tFzUQ0/YT9YsFjt0oCzHdItdpQgTqbRv7d86bgmMNGL2IuUT8GLscluJYX?=
 =?us-ascii?Q?wilwYdZAdxFiZNyEcw2tXXiwBcsaJBwRHQZUkLCWKml28k9cMEJIh5BIM9jI?=
 =?us-ascii?Q?C/qa0/MpIFF1Gdb9dcCoeduYihSdl0ZxkElmaw+vljH47Fav1amarghBZ/HT?=
 =?us-ascii?Q?womAD333SVIjTXViKErn0EjzPyrN2APvgf3WeDTGgBBiX4D2BFxgCJjLF3DW?=
 =?us-ascii?Q?kgPHjM6u2HTXxt46gybkheba2+PGlwdrFJ8bRG0Kcp6hv6LzJ0kbLdebxCa2?=
 =?us-ascii?Q?YqAGPcf3LU71vFAePx+yHt0qKZYpc4R7zojP05uJaIrwMWpnuEWzOGKuvfAd?=
 =?us-ascii?Q?h2TVgHKWfbufCBeKlExuLjDQWAXGst1mkpd4nQe/rDhjYTXSNNIdBX58UJ39?=
 =?us-ascii?Q?g2q/oz67S1u3CYTpzq+r9P4X31qFnd3WbPhKjVI4DthsJ413aWgjFENW+uYz?=
 =?us-ascii?Q?j3/FLwREVJnFVb9kmrsF42Ww3U9rUG8yCA+mtnKIviVnRPTji4vEMa/Y/mPp?=
 =?us-ascii?Q?Wdehev0mK2MJj5XEwm/QNNUljaJFrduMnrRUF/GvfXoEBMGKJ5LxAITJVMJ9?=
 =?us-ascii?Q?64W3LrmLLCKNO+Ga53a4qYthpCiVX07vBjlFGKh20u1BuWJpTukBmRj4pmsj?=
 =?us-ascii?Q?0/HfOFnv6moBJbVaAkH8jWPMVrQbKef9DjkhDZO0GpZnZRY+7HBLRbKvi3kC?=
 =?us-ascii?Q?og6E+hrrU0kLWWj2IVrOgjWigU/QX/yMMHnsdMZWJBGgu7ohK3Od5XFJ9f/9?=
 =?us-ascii?Q?Tav6v4S7PUWeZ0gK6SJKoajB0f/HSjU8MFsWLZMVVM8gEUIA/lgCRx7Xplvm?=
 =?us-ascii?Q?QmcoE2Vd07kqeHQsc80Ikncj0pPC52hMdMtaQPyEsORy5Y7zItRAbcG5ygTG?=
 =?us-ascii?Q?WORYuRiKKjTGsk60gO/TRxXx387yIchZVf5FMJ3HnNZxrUuatdKpUNxBhWP4?=
 =?us-ascii?Q?F6ClXSIWO5ubQh3vb0sDUphCrtjiyOvot1cpUMq6mnQfaDDoqafiOib+FQzC?=
 =?us-ascii?Q?zDlVTPyDlxq3PyI8pWI+xpAtWsIR1P/ADTOPcHtJ+Y3jwR/SZoMEqCqbw3cm?=
 =?us-ascii?Q?CbQukS8lic/mI4VYXK5IgGurgYgKEbpldgk5j2fBtf1DPIWEKpply9pjwjTq?=
 =?us-ascii?Q?aZyWSe7YJbHM2eeD/s2uii0=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <09A049454DBD184F824667E68B8883A6@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: 401f1955-8e78-41ce-ea61-08d9ea6d65b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2022 19:09:42.7126
 (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: 7bWIKyjqXh3jC/UgQgLtPvcVpYHafPmVQlyt5/ayXfpOL+G1PRkRZKrgnL7d+c/EK2xr70edKyWu4D1Tidy0sA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR10MB4312
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10251 signatures=673430
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 bulkscore=0
 phishscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 spamscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2202070116
X-Proofpoint-GUID: odfNImTrFPyEfJJDDM3Gqwz2pi36pete
X-Proofpoint-ORIG-GUID: odfNImTrFPyEfJJDDM3Gqwz2pi36pete
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 4, 2022, at 3:55 PM, Patrick Goetz <pgoetz@math.utexas.edu> wrote:
>=20
>=20
>=20
> On 2/2/22 13:55, Chuck Lever III wrote:
>>> On Feb 1, 2022, at 8:41 PM, Simon Kirby <sim@hostway.ca> wrote:
>>>=20
>>> How far off would we be from write delegations happening here?
>> We are tracking a "feature request" for write delegation support
>> in the Linux NFS server:
>> https://bugzilla.linux-nfs.org/show_bug.cgi?id=3D348
>> At this point the effort is not resourced. It's not clear how
>> much benefit it would be.
>=20
> First shock is I thought write delegation was already supported.

WRITE delegation and READ delegation are both supported on
the Linux NFS client.

The Linux NFS server offers only READ delegations.


> But especially for users who have NFS mounted home directories, how could=
 there not be a major performance benefit? To cite one example that has bee=
n a problem before (in particular, on Mac OSX clients with NFSv3 home direc=
tories mounted from a linux fileserver), facilitating the firefox "awesome"=
 bar, which writes to a SQLlite database in ~/.mozilla/fireworks with alarm=
ing frequency in order to keep up the awesomeness.

I might be missing something, but if SQlite is using fsync()
then there isn't much choice for the NFS client but to push
dirty data to the server and see that the data is committed.
The purpose of that fsync() is to ensure the written data is
robust against client or server failure.

WRITE delegation would probably not have much impact on that.
It's purpose is to enable the client to cache more aggressively
in cases where immediate data persistence is not needed.

The fact that there is only one client reading and updating
that database is beside the point.


> This flat out didn't work previously unless you went to about:config and =
set
>=20
>  storage.nfs_filesystem =3D true
>=20
> Not at all sure how this changed the execution of firefox though.
>=20
>=20
>> That said, it seems to me that your use case might benefit if
>> the Linux NFS server offered a READ delegation for the SQLite
>> database file even when it is open R/W. It might be appropriate
>> if the server offered such a delegation when there are no other
>> clients that have the file open for write or that hold write
>> delegations.
>> Patches and performance data are, as always, welcome.
>> --
>> Chuck Lever

--
Chuck Lever