Subject: RE: [nfsv4] Sleepy clients

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 25 Aug 2005 17:30:50 -0400

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.  

It seems that if the client is going to sleep it should give
up any delegations it holds.  If it does that then in the 
typical Unix environment, lock conflicts would be failry 
infrequent since people open files without deny modes.

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?

-----Original Message-----
From: Brent Callaghan [mailto:[email-masked]] 
Sent: Thursday, August 25, 2005 5:17 PM
To: [email-masked]
Subject: [nfsv4] Sleepy clients

My workstation goes to sleep if I leave it idle for more than 15  
minutes.

It turns the display, fans and disk off and the rest of it goes into
snooze mode.  It transmits and receives nothing on the network while
it's asleep.  My laptop does the same thing - it also goes to sleep  
almost
instantly if I close it.

As an NFSv4 client, I presume the server would deal with this behavior
rather harshly.  The server would assume that a "network partition" had
occurred and at lease expiration it would take action to revoke the
sleeping client's open files, delegations, locks etc.

RFC3530 makes no mention of sleepy clients, though it does
describe what should happen if a network partition should occur.
Section 8.6.3 says that the client is responsible for re-establishing
any state lost after a network partition that causes a lease to expire -
and mentions that "network partitions are relatively rare."
However, client sleeps can be *very* frequent.  My workstation sleeps
about half a dozen times a day and some laptop users go through the
sleep/wakeup cycle dozens of times a day. That's a lot of state  
recovery,
lost locks, and potential for app breakage.

If the client could tell the server that it's going to sleep, then  
the server
could use that as a hint that it should hold off destroying the client's
state when its lease expires, e.g.

	OP_ZZZZ  <clientid>

	The client is going to sleep for an indeterminate time and will
	be unable to RENEW its lease. The server SHOULD automatically
	extend the client's lease for as long as possible, or until the

client resumes
	activity.

This would be simple to implement - and provide a more stable service
for sleepy clients.  The server could establish a configurable upper  
limit
on how long it's going to wait for the client to wake up (perhaps one or
two days).

Opinions ?

	Thanks
		Brent

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

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 25 Aug 2005 18:00:45 -0500

> expiration and only do it when there is a conflict.  Our

I believe that this is sufficient.

> infrequent since people open files without deny modes.

Hopefully the user hasn't already disconnect the network.

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Thu, 25 Aug 2005 16:55:17 -0700

What about itinerant laptops as well as sleepy?
Is it possible, even likely, that when a laptop
goes to sleep that when it wakes up it will be
in a different place and negotiate a new IP address?
Doesn't this complicate preservation of client
state on the server side? And recovery?

No suggestion here. Sleepy clients is an interesting
wrinkle and it made be curious about itinerant.

Regards,
	-gww

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Spencer Shepler
> Sent: Thursday, August 25, 2005 4:01 PM
> To: Noveck, Dave
> Cc: [email-masked]; Brent Callaghan
> Subject: Re: [nfsv4] Sleepy clients
> 
>