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;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: nfs home directory and google chrome.
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <031501d69cb6$f6843a10$e38cae30$@mindspring.com>
Date:   Wed, 7 Oct 2020 11:39:58 -0400
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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FB71E67-8814-4C62-A9E0-CF7A4D10735F@oracle.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>
To:     Frank Filz <ffilzlnx@mindspring.com>
Precedence: bulk


> On Oct 7, 2020, at 10:34 AM, Frank Filz <ffilzlnx@mindspring.com> =
wrote:
>=20
>> -----Original Message-----
>> From: J. Bruce Fields [mailto:bfields@fieldses.org]
>> Maybe I overlooked the obvious: if Chrome holds a lock on that file =
when you
>> suspend, and if you stay in suspend for longer than the NFSv4 lease =
time (default
>> 90 seconds), then the client will lose its lease, hence any file =
locks.  I think these
>> days the client then returns EIO on any further IO to that file =
descriptor.
>>=20
>> Maybe there's some way to turn off that locking as a workaround.
>>=20
>> The simplest thing we can do to help might be implementing "courteous =
server"
>> behavior: instead of automatically removing locks after a client's =
lease expires,
>> it can wait until there's an actual lock conflict.  That might be =
enough for your
>> case.
>>=20
>> There's been a little planning done and it's not a big project, but I =
don't think it's
>> actually at the top of anyone's todo list right now, so I'm not sure =
when that will
>> get done.
>=20
> I've had courtesy locks on my back burner for Ganesha though I hadn't =
thought about that there might actually be an important practical issue.

We've found that instantly bringing the hammer down on NFSv4 leases has
negative operational consequences in environments where minutes-long
network partitions are part of life.

Extending the lease period impacts the length an NFS server is in grace
after a reboot, so it's not always a good solution.


> Does any other server implement them? If we suggest this as a solution =
to the Chrome suspend issue, it might be good to assure that the major =
server vendors implement this.

We think OnTAP does, at least.


> There is a problem with the courtesy locks for this solution though... =
The clientid is still going to be expired, and the locks are associated =
with the clientid, so unless we allow courtesy re-instatement of expired =
clientids, courtesy locks don't actually solve the problem...

An NFSv4 server is not required to expire a lease after the lease period
expires.

A courteous server would simply allow a conflicting lock request to take
an expired lock after a client's lease expired. If no conflicting lock
operations occur, then the missing client could come back and find its
lease state intact (unless of course the server has restarted or purged
the lease for other reasons).

Oracle has an open design document that can be posted here for more
comment and review. We agree that this is much better server behavior
and would like more server implementations to adopt it.


> Option - use NFSv3 instead :-) The lack of lock expiry due to AWOL =
client would work in a suspended client's favor... Note also that a =
suspended client could be a VM, for example, VirtualBox allows saving =
and suspending a VM in running state.
>=20
> Interesting problem...
>=20
> Frank
>=20

--
Chuck Lever