Subject: RE: [nfsv4] Sleepy clients and NFSv4.1

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 7 Apr 2006 14:31:46 -0400

I think the most relevant current section is 6.6.3.  This deals with
maintaining lock state even in the event that leases expire.  It sounds
like you'd like to make this a little bit stronger than the current
"As a courtesy to the client or as an optimization, the server may".
I'm guessing there'll be considerable discussion about exactly what 
the right modal auxiliary is.  Is lower-case "should" in line with 
what you were thinking?

-----Original Message-----
From: Brent Callaghan [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 1:35 PM
To: [email-masked]
Subject: [nfsv4] Sleepy clients and NFSv4.1

Last August we discussed the problem of sleeping clients.  It's common  
now for
clients, such as laptops and power-conserving desktops, to power down  
into a
sleep mode.  In this mode applications may be holding locks or  
continue to
have files open, but inactive, yet the client is unable to renew its  
state on the
server.  On awakening from a sleep, a client is likely to find that  
the server
thinks it has crashed, and locks are lost.

I speculated on the use of an OP_ZZZZ operation that the client could  
issue
prior to sleeping, that would be an advisory to the server to attempt to
preserve the client's state even if it expires.  The effect of OP_ZZZZ  
would
be cancelled automatically on the client resuming normal NFS operation.

Although the OP_ZZZZ advisory would allow a server to avoid an  
unnecessary
delegation callback and timeout, there could be some problems in  
implementation.
For instance, a multi-threaded client might find it difficult to  
guarantee that
OP_ZZZZ is the last NFS call issued before sleep, and it's possible  
that the
user might just pull the plug on the network before closing the laptop  
lid,
preempting any OP_ZZZZ call.

The consensus seemed to be that it would be better if the server  
implemented
a policy just to preserve client state even after that state expires  
as long as
no conflict arises, e.g. if the sleeping client holds a lock that  
blocks another
client.

However, there's no mention of sleeping clients in the current NFSv4.1
draft, or any recommendation to preserve expired state.  I'd like to
suggest we add a small section in the v4.1 draft to do that.  However,
looking over the draft, I don't see an obvious place to add it.

Any suggestions for where in the draft to put this discussion, or
for any text to recommend state preservation ?

	Ta
		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