Subject: [nfsv4] d19 and Device stateids.

From: Robert Gordon <[email-masked]>
Date: Tue, 12 Feb 2008 01:40:22 -0600

That got your attention didn't it :)

There is still some clean-up with respect to DELEGRETURN
in connection to deviceid notifications and the status bits
in sf_status_flags.

Here is a stab at some alterations for everyone to poke holes in..

====
  diff -u nfsv41_middle_op_sequence.xml  
rbg_nfsv41_middle_op_sequence.xml
--- nfsv41_middle_op_sequence.xml	2007-12-17 16:17:39.000000000 -0600
+++ rbg_nfsv41_middle_op_sequence.xml	2008-02-12 01:22:25.000000000  
-0600
@@ -216,18 +216,17 @@
  	  The client is using device ID notifications and the server
  	  has changed a device ID mapping held by the client. This
  	  flag will stay present until the client has obtained the new
-	  mapping with GETDEVICELIST or GETDEVICEINFO.
+	  mapping(s) with GETDEVICEINFO.
  	</t>
  	<t hangText="SEQ4_STATUS_DEVID_DELETED"><vspace />
-	  The server has removed a device ID mapping as held by the
-	  client.  This flag will stay in affect until the client
-	  either sends a DELEGRETURN or uses GETDEVICELIST to
-	  refresh all mappings.
+	  The client is using device ID notifications, the server has
+	  removed a device ID mapping held by the client.  This
+	  flag will stay in affect until the client uses GETDEVICEINFO
+	  with a null gdia_notify_type.
  	</t>
  	<t hangText="SEQ4_STATUS_DEVID_DELETED_ALL"><vspace />
  	  The server has deleted all device ID mappings; this flag
-	  will stay present until the client sends the appropriate
-	  DELEGRETURN.
+	  will stay present until the client sends a GETDEVICELIST.
  	</t>
        </list>
===

If a client sees SEQ4_STATUS_DEVID_DELETED_ALL; Do we expect an
implementation to perhaps iterate over it's open state and build
one large compound with a GETDEVICEINFO for each 'active' device id ??

One more thing; Should we discuss making deviceid notifications  
REQUIRED ?

Robert.
_______________________________________________
nfsv4 mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 12 Feb 2008 09:01:00 -0500

> +	  will stay present until the client sends a GETDEVICELIST. 

So note that now GDL is per-fs.  This means that the use of it to
bracket such a notification is somewhat arbitrary.  For example, when
GDL was global, then if I issued such an op at any time then this was
going on, even if it was imediately after the delete, then turning the
bit off is no problem.  If I don't see the status, I see an empty GDL
response and so I got the information that the notification was
prompting me to get.  If GDL is per-fs, then its use in this context is
kind of artificial and you worry about the case in which a GDL happened
to be in-flight when the DELETE-ALL occurred.

I'm wondering about what the need for this status  bit is.

-----Original Message-----
From: Robert Gordon [mailto:[email-masked]] 
Sent: Tuesday, February 12, 2008 2:40 AM
To: NFSv4
Subject: [nfsv4] d19 and Device stateids.

There is still some clean-up with respect to DELEGRETURN in connection
to deviceid notifications and the status bits in sf_status_flags.

====
--- nfsv41_middle_op_sequence.xml	2007-12-17 16:17:39.000000000

If a client sees SEQ4_STATUS_DEVID_DELETED_ALL; Do we expect an
implementation to perhaps iterate over it's open state and build one
large compound with a GETDEVICEINFO for each 'active' device id ??

One more thing; Should we discuss making deviceid notifications REQUIRED
?

Robert.

---

From: Mike Eisler <[email-masked]>
Date: Tue, 12 Feb 2008 06:09:53 -0800 (PST)

> I'm wondering about what the need for this status  bit is.

I'm not wondering ... I think it should be deleted. Which is what
I will do unless anyone can convince me we had a rough consensus to
do otherwise.

> REQUIRED

---

From: Robert Gordon <[email-masked]>
Date: Tue, 12 Feb 2008 09:44:20 -0600

I think that deleting it is fine.

---

From: Mike Eisler <[email-masked]>
Date: Thu, 14 Feb 2008 06:59:34 -0800 (PST)

These are the diffs I would like to check in:

Index: nfsv41_middle_op_sequence.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_sequence.xml,v
retrieving revision 1.33
diff -u -r1.33 nfsv41_middle_op_sequence.xml
--- nfsv41_middle_op_sequence.xml       17 Dec 2007 22:17:39 -0000     
1.33
+++ nfsv41_middle_op_sequence.xml       14 Feb 2008 14:57:33 -0000
@@ -216,18 +216,13 @@
          The client is using device ID notifications and the server
          has changed a device ID mapping held by the client. This
          flag will stay present until the client has obtained the new
-         mapping with GETDEVICELIST or GETDEVICEINFO.
+         mapping with GETDEVICEINFO.
        </t>
        <t hangText="SEQ4_STATUS_DEVID_DELETED"><vspace />
-         The server has removed a device ID mapping as held by the
-         client.  This flag will stay in affect until the client
-         either sends a DELEGRETURN or uses GETDEVICELIST to
-         refresh all mappings.
-       </t>
-       <t hangText="SEQ4_STATUS_DEVID_DELETED_ALL"><vspace />
-         The server has deleted all device ID mappings; this flag
-         will stay present until the client sends the appropriate
-         DELEGRETURN.
+         The client is using device ID notifications and the server
+         has deleted a device ID mapping held by the client.
+          This flag will stay in affect until the client sends
GETDEVICEINFO
+          with a null value in the argument gdia_notify_types.
        </t>
       </list>
     </t>
cvs diff: Diffing dotx-id.d
cvs diff: Diffing dotx.d
Index: dotx.d/sequence_res.x
===================================================================
RCS file: /cvs/stdk/NFSv41/dotx.d/sequence_res.x,v
retrieving revision 1.8
diff -u -r1.8 sequence_res.x
--- dotx.d/sequence_res.x       31 Oct 2007 09:15:06 -0000      1.8
+++ dotx.d/sequence_res.x       14 Feb 2008 14:57:33 -0000
@@ -11,7 +11,6 @@
 const SEQ4_STATUS_BACKCHANNEL_FAULT            = 0x00000400;
 const SEQ4_STATUS_DEVID_CHANGED                        = 0x00000800;
 const SEQ4_STATUS_DEVID_DELETED                        = 0x00001000;
-const SEQ4_STATUS_DEVID_DELETED_ALL            = 0x00002000;

 struct SEQUENCE4resok {
        sessionid4      sr_sessionid;

--- Mike Eisler <[email-masked]> wrote:

> > prompting me to get.  If GDL is per-fs, then its use in this
> context
> > is
> one

---

From: Robert Gordon <[email-masked]>
Date: Thu, 14 Feb 2008 15:42:23 -0600

> These are the diffs I would like to check in:

looks good to me.

--
Robert...
"Don't Make Assumptions"