> On Oct 7, 2020, at 2:11 PM, Frank Filz <ffilzlnx@xxxxxxxxxxxxxx> wrote: > > > >> -----Original Message----- >> From: Chuck Lever [mailto:chuck.lever@xxxxxxxxxx] >> Sent: Wednesday, October 7, 2020 8:40 AM >> To: Frank Filz <ffilzlnx@xxxxxxxxxxxxxx> >> Cc: Bruce Fields <bfields@xxxxxxxxxxxx>; Kenneth Johansson > <ken@xxxxxxxxx>; >> Patrick Goetz <pgoetz@xxxxxxxxxxxxxxx>; Linux NFS Mailing List <linux- >> nfs@xxxxxxxxxxxxxxx> >> Subject: Re: nfs home directory and google chrome. >> >> >> >>> On Oct 7, 2020, at 10:34 AM, Frank Filz <ffilzlnx@xxxxxxxxxxxxxx> wrote: >>> >>>> -----Original Message----- >>>> From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] 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
