Subject: re: [nfsv4] sleepy clients

From: [email-masked]
Date: Fri, 26 Aug 2005 11:47:59 -0400 (EDT)

Lots of good stuff deleted for the sake of brevity.
[Dave wrote]
> The server is allowed to avoid getting rid of locks at lease 
> expiration and only do it when there is a conflict.  Our
> server does this.  

As does mine. (ie: Only releases expired state when there is a conflicting
request or state storage limits are hit.) Further, I would like to
encourage other server implementors to take the same approach, when practicable.
Along with sleepy clients, here's a local case:
- In one of the buildings I administer systems in, about half of one floor
  becomes network partitioned for 1-5min. about once a day. (The campus
  networking people are working on this, but haven't resolved the problem
  yet.) I don't run NFSv4 in production mode, but image what this would
  do if I was and the servers released state as soon as leases expired.
  (I'd be switching back to NFSv3 mighty quickly:-)

[Brent wrote]
> If the client's asleep, the server won't be able to recall a  
> delegation anyway.
> At least with an OP_ZZZZ notification, the server can avoid messing  
> around
> with a recall.

If a client returns delegations before going to sleep, then this isn't an
issue (which I agree with others should be done).

[Dave and Brent wrote]
>> With your proposed hint, are you expecting the server to hold
>> off on lock revocation when there is a conflict, or only in
>> the expired-but-no-conflict-yet case?
>
>I'd expect the server to maintain the client's locks - just as
>it would if the client were awake but idle.  However, since
>OP_ZZZZ compliance would be a "should", the server could
>just expire the lease if a conflict occurs.

I admit your answer wasn't clear to me? If it is a hint for the server
to hold onto state as long as practicable, I support that, but feel the
server should do that for all clients.

If, on the other hand, you want servers to hold onto state even when a
conflicting request from a different client is received by the server,
then I do see that as troublesome.
- When I put on my sysadmin hat, I envision running all over the place
  trying to figure out where the client that is holding onto this state
  is, when someone complains they can't access a file, due to a locking
  or open share conflict. (In practice, I'd probably just go and Admin
  Revoke the state, because I'm too old and lazy to go running around.:-)

[Brent wrote]
> Heh, I can imagine some kind of interlock that prevents you
> closing the lid on your laptop - not sure if customers would see
> that as a feature though :-)

Isn't the problem disconnecting from the network, not closing the case?
I'd suggest a large capacitor discharge into the laptop's outer case
whenever someone tries to unplug the net cable (or move the laptop
when wireless is in use). I'm sure your customers would appreciate that:-)

rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 26 Aug 2005 10:59:27 -0500

>   (I'd be switching back to NFSv3 mighty quickly:-)

For normal open files, the client should be able to recover by reopening
the file.  Just as if there were a partition for the NFSv3 client.
It keeps working.  Only in the case of existing file locks would there
be an issue.

Spencer