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;
IronPort-SDR: Lk7i97gXTbgmd1DftLjPwxN/wU421n/YimuND6VXZ4U9JyYZ5cQiIIxLjUt1hce4PSY8V2dynj
 ubj1L18hB6iZOf4X4kjGZCp99gJa1GrBo8QstoFkI8p0H8FNukoZM6vMEM9E9ODKRt/kUtXUVk
 sy8A5J6ybIlH4JaMkxtdpRXqweBQStTPHHwhJy/XlZb/AqfZPJZi+yZENkBKks9QfLa5HGIZ6B
 yB31V4YGCfK4+lMOkOKH6qlaMUifFR7E9RoGLPgrbNtb8JtjcX/uKPJ0akpEHGz3y4/a7gqnD0
 LYI=
From:   "inoguchi.yuki@fujitsu.com" <inoguchi.yuki@fujitsu.com>
To:     "'J. Bruce Fields'" <bfields@fieldses.org>,
        "'linux-nfs@vger.kernel.org'" <linux-nfs@vger.kernel.org>
Subject: RE: client caching and locks
Thread-Topic: client caching and locks
Thread-Index: AQHWPdqMcAycEC0/pke1JkGmPD8pPKjeL0Ew
Date:   Thu, 18 Jun 2020 09:54:32 +0000
Deferred-Delivery: Thu, 18 Jun 2020 09:55:30 +0000
Message-ID: <OSBPR01MB2949040AA49BC9B5F104DA1FEF9B0@OSBPR01MB2949.jpnprd01.prod.outlook.com>
References: <20200608211945.GB30639@fieldses.org>
In-Reply-To: <20200608211945.GB30639@fieldses.org>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 01f8c8fc-4be8-4adf-e6ca-08d8136dc71b
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 09:55:48.4833
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a19f121d-81e1-4858-a9d8-736e267fd4c7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: torP+nptotpDn0ch+JUxnz8J3y0ZlnMqIncFBPQusr//pfwgKcbtv3uXs3NHHDxA6yFmUWioF895704cksZNtnt6/a3iw7+T+AUF7aS/ELU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2520
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

> What does the client do to its cache when it writes to a locked range?
>=20
> The RFC:
>=20
> 	https://tools.ietf.org/html/rfc7530#section-10.3.2
>=20
> seems to apply that you should get something like local-filesystem
> semantics if you write-lock any range that you write to and read-lock
> any range that you read from.
>=20
> But I see a report that when applications write to non-overlapping
> ranges (while taking locks over those ranges), they don't see each
> other's updates.
>=20
> I think for simultaneous non-overlapping writes to work that way, the
> client would need to invalidate its cache on unlock (except for the
> locked range).  But i can't tell what the client's designed to do.

Simultaneous non-overlapping WRITEs is not taken into consideration in RFC7=
530.
I personally think it is not necessary to deal with this case by modifying =
the kernel because
the application on the client can be implemented to avoid it.

Serialization of the simultaneous operations may be one of the ways.
Just before the write operation, each client locks and reads the overlapped=
 range of data
instead of obtaining a lock in their own non-overlapping range.
They can reflect updates from other clients in this case.

Yuki Inoguchi

>=20
> --b.