RE: nfs home directory and google chrome.

["Frank Filz" <ffilzlnx@mindspring.com>]

> -----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.

Thanks

Frank