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:   Rick Macklem <rmacklem@uoguelph.ca>
To:     Frank Filz <ffilzlnx@mindspring.com>,
        'Chuck Lever' <chuck.lever@oracle.com>
CC:     'Bruce Fields' <bfields@fieldses.org>,
        'Kenneth Johansson' <ken@kenjo.org>,
        'Patrick Goetz' <pgoetz@math.utexas.edu>,
        'Linux NFS Mailing List' <linux-nfs@vger.kernel.org>
Subject: Re: nfs home directory and google chrome.
Thread-Topic: nfs home directory and google chrome.
Thread-Index: AQHWnJhPwrgZeWL3Q0WXswuosTP8pKmMHU6AgAAXbICAABJOAIAAKlCAgABdcDQ=
Date:   Wed, 7 Oct 2020 23:58:04 +0000
Message-ID: <YTBPR01MB396679E8135015A360ADDC79DD0A0@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM>
References: <0ba0cd0c-eccd-2362-9958-23cd1fa033df@kenjo.org>
 <5326b6a3-0222-fc1a-6baa-ae2fbdaf209d@math.utexas.edu>
 <923003de-7fcf-abee-07a2-0691b25673d8@kenjo.org>
 <20201006181454.GB32640@fieldses.org>
 <07f3684e-482e-dc73-5c9a-b7c9329fc410@kenjo.org>
 <20201007131037.GA23452@fieldses.org>
 <031501d69cb6$f6843a10$e38cae30$@mindspring.com>
 <1FB71E67-8814-4C62-A9E0-CF7A4D10735F@oracle.com>,<033c01d69cd5$46358cd0$d2a0a670$@mindspring.com>
In-Reply-To: <033c01d69cd5$46358cd0$d2a0a670$@mindspring.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a58cf9e-abc8-400b-ec9e-08d86b1cd4c1
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2020 23:58:04.4451
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: V/6qbKHg0Ux3Khc8RX1wT0k1oS/Xc8OeQfuuTwQwPmO46yXDJ2TVuTm4DbXNrw6rRBTP+6vl4gQwlRR/XO5+5g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3694
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

Frank Filz wrote:=0A=
>> -----Original Message-----=0A=
>> From: Chuck Lever [mailto:chuck.lever@oracle.com]=0A=
>> Sent: Wednesday, October 7, 2020 8:40 AM=0A=
>> To: Frank Filz <ffilzlnx@mindspring.com>=0A=
>> Cc: Bruce Fields <bfields@fieldses.org>; Kenneth Johansson=0A=
<ken@kenjo.org>;=0A=
>> Patrick Goetz <pgoetz@math.utexas.edu>; Linux NFS Mailing List <linux-=
=0A=
>> nfs@vger.kernel.org>=0A=
>> Subject: Re: nfs home directory and google chrome.=0A=
>>=0A=
>>=0A=
>>=0A=
>> > On Oct 7, 2020, at 10:34 AM, Frank Filz <ffilzlnx@mindspring.com> wrot=
e:=0A=
>> >=0A=
>> >> -----Original Message-----=0A=
>> >> From: J. Bruce Fields [mailto:bfields@fieldses.org] Maybe I=0A=
>> >> overlooked the obvious: if Chrome holds a lock on that file when you=
=0A=
>> >> suspend, and if you stay in suspend for longer than the NFSv4 lease=
=0A=
>> >> time (default=0A=
>> >> 90 seconds), then the client will lose its lease, hence any file=0A=
>> >> locks.  I think these days the client then returns EIO on any further=
=0A=
IO to that=0A=
>> file descriptor.=0A=
>> >>=0A=
>> >> Maybe there's some way to turn off that locking as a workaround.=0A=
>> >>=0A=
>> >> The simplest thing we can do to help might be implementing "courteous=
=0A=
>> server"=0A=
>> >> behavior: instead of automatically removing locks after a client's=0A=
>> >> lease expires, it can wait until there's an actual lock conflict.=0A=
>> >> That might be enough for your case.=0A=
>> >>=0A=
>> >> There's been a little planning done and it's not a big project, but I=
=0A=
>> >> don't think it's actually at the top of anyone's todo list right now,=
=0A=
>> >> so I'm not sure when that will get done.=0A=
>> >=0A=
>> > I've had courtesy locks on my back burner for Ganesha though I hadn't=
=0A=
thought=0A=
>> about that there might actually be an important practical issue.=0A=
>>=0A=
>> We've found that instantly bringing the hammer down on NFSv4 leases has=
=0A=
>> negative operational consequences in environments where minutes-long=0A=
>> network partitions are part of life.=0A=
>>=0A=
>> Extending the lease period impacts the length an NFS server is in grace=
=0A=
after a=0A=
>> reboot, so it's not always a good solution.=0A=
>>=0A=
>>=0A=
>> > Does any other server implement them? If we suggest this as a solution=
=0A=
to the=0A=
>> Chrome suspend issue, it might be good to assure that the major server=
=0A=
vendors=0A=
>> implement this.=0A=
>>=0A=
>> We think OnTAP does, at least.=0A=
>>=0A=
>>=0A=
>> > There is a problem with the courtesy locks for this solution though...=
=0A=
The=0A=
>> clientid is still going to be expired, and the locks are associated with=
=0A=
the clientid,=0A=
>> so unless we allow courtesy re-instatement of expired clientids, courtes=
y=0A=
locks=0A=
>> don't actually solve the problem...=0A=
>>=0A=
>> An NFSv4 server is not required to expire a lease after the lease period=
=0A=
expires.=0A=
The way the FreeBSD server is implemented is that does not expire a clientI=
D=0A=
(and all associated open/byte range lock state) when a lease expires.=0A=
However, a conflicting Open/Lock request results in the ClientID and all=0A=
associated opens/byte range locks being expired at that point in time.=0A=
=0A=
I was never sure if a NFSv4 client would expect NFS4ERR_EXPIRED to be=0A=
returned for some lock, but not all state related operations. so I chose=0A=
to expire ClientID + all Opens and Locks at the same time.=0A=
--> However, this is only triggered by a conflicting Open/Lock request or=
=0A=
      server resource depletion and not simply a client failing to renew a =
lease.=0A=
=0A=
rick=0A=
ps: It has been like this for almost 20years and I have not heard of it=0A=
      causing problems.=0A=
=0A=
>=0A=
> A courteous server would simply allow a conflicting lock request to take=
=0A=
an=0A=
> expired lock after a client's lease expired. If no conflicting lock=0A=
operations occur,=0A=
> then the missing client could come back and find its lease state intact=
=0A=
(unless of=0A=
> course the server has restarted or purged the lease for other reasons).=
=0A=
>=0A=
> Oracle has an open design document that can be posted here for more=0A=
> comment and review. We agree that this is much better server behavior and=
=0A=
> would like more server implementations to adopt it.=0A=
=0A=
Ah that document would be helpful. Does the document discuss conditions=0A=
where a server might abandon a courtesy hold on a client id and expire it=
=0A=
out anyway? For example, to conserve resources.=0A=
=0A=
Thanks=0A=
=0A=
Frank=0A=
=0A=
=0A=