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: <033c01d69cd5$46358cd0$d2a0a670$@mindspring.com>
Date:   Wed, 7 Oct 2020 14:36:21 -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: 7bit
Message-Id: <07BAF542-7513-4E96-873E-3F815E6FDBB1@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>
 <1FB71E67-8814-4C62-A9E0-CF7A4D10735F@oracle.com>
 <033c01d69cd5$46358cd0$d2a0a670$@mindspring.com>
To:     Frank Filz <ffilzlnx@mindspring.com>
Precedence: bulk


> On Oct 7, 2020, at 2:11 PM, Frank Filz <ffilzlnx@mindspring.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Chuck Lever [mailto:chuck.lever@oracle.com]
>> Sent: Wednesday, October 7, 2020 8:40 AM
>> To: Frank Filz <ffilzlnx@mindspring.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.
>> 
>> 
>> 
>>> On Oct 7, 2020, at 10:34 AM, Frank Filz <ffilzlnx@mindspring.com> wrote:
>>> 
>>>> -----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.
>>>> 
>>>> Maybe there's some way to turn off that locking as a workaround.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>> 
>>> 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.
> 
> Ah that document would be helpful. Does the document discuss conditions
> where a server might abandon a courtesy hold on a client id and expire it
> out anyway? For example, to conserve resources.

Yes. It covers appropriate server responses to a client to report that
it has done this.

Bill will post the document soon in a separate thread.

--
Chuck Lever