Frank Filz 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. The way the FreeBSD server is implemented is that does not expire a clientID (and all associated open/byte range lock state) when a lease expires. However, a conflicting Open/Lock request results in the ClientID and all associated opens/byte range locks being expired at that point in time. I was never sure if a NFSv4 client would expect NFS4ERR_EXPIRED to be returned for some lock, but not all state related operations. so I chose to expire ClientID + all Opens and Locks at the same time. --> However, this is only triggered by a conflicting Open/Lock request or server resource depletion and not simply a client failing to renew a lease. rick ps: It has been like this for almost 20years and I have not heard of it causing problems. > > 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
