Subject: RE: [nfsv4] Sleepy clients

From: "wurzl, mario" <[email-masked]>
Date: Thu, 25 Aug 2005 17:24:51 -0400

Shouldn't the client flush all the date and close any open file before going
to sleep ?

Having a OP_ZZZ operation, creates the problem that a server will be unable
to recall a delegation while
The client sleep time has not expired.

Mario

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brent Callaghan
Sent: Thursday, August 25, 2005 17:17
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: Brent Callaghan <[email-masked]>
Date: Thu, 25 Aug 2005 14:49:29 -0700

> Shouldn't the client flush all the date and close any open file  

Yes, it's a good goal for the client to minimize the amount of  
uncommitted state,
though there's little it can do to persuade its apps to flush data,  
close files
or remove locks.

> The client sleep time has not expired.

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.

Dave Noveck wrote:
> 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.

Yes, it's reasonable that the client return any delegations
before sending an OP_ZZZZ.

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

J. Bruce Fields wrote:
> Only the obvious--I've also seen laptops that wake up unreliably.  I
> also usually forget to unmount before taking my laptop home with me.
> Can the server really be expected to hold locks for a client for hours
> or days?

It holds locks for clients that are awake but idle - so it shouldn't
be any harder for a sleeping client.

> It sounds like an unsolveable problem.  Maybe the OS can just  
> refuse to
> sleep while it's holding locks on a network filesystem?

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 :-)

	Brent

---

From: Omer Asad <[email-masked]>
Date: Thu, 25 Aug 2005 14:51:57 -0700

Its an interesting problem to solve. There are no clear solutions.

But to have an OP_ZZZ() operation could dictate what can be done in
such a situation. If a client detects that its OS is going to sleep
it can issue an OP_ZZZ. This operation could tell the server to
extend its lease invariably or for whatever time the server may
feel is good for a sleepy client.

Once the client issues an OP_ZZZ it should also send back any
delegations that it has and a state of all its locks. If the locks
are conflicting, the server should revoke them or ask the client
to close the file.

OP_ZZZ could comprise of a compound, returning a delegation,
the lock state and a flush of all the file info(write/read) state.
Once the client wakes up , it can re-establish state sorta like
NFSv4 recovery stuff.

Thanks,
-Omer