Subject: [nfsv4] CB_NOTIFY_DEVICEID info missing in -25

From: Dean Hildebrand <[email-masked]>
Date: Wed, 15 Oct 2008 16:21:12 -0700

I just noticed that CB_NOTIFY_DEVICEID is missing a few things in the 
NFSv4.1 version 25 draft.

a) It is missing from the table in Section 15.3
b) Page 392, CB_NOTIFY_DEVICEID points to the wrong section.  It should 
be 20.12.

Also, I don't see a max size listed anywhere for the cnda_changes<> 
array in the CB_NOTIFY_DEVICEID4args struct.  So if a server sends too 
many device notifications in a callback, should the client return an 
error or just process as many as it can?  If it does return an error, 
should it still process the notifications?

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

---

From: Robert Gordon <[email-masked]>
Date: Thu, 16 Oct 2008 08:25:26 -0500

On Oct 15, 2008, at 6:21 PM, Dean Hildebrand wrote:
> array in the CB_NOTIFY_DEVICEID4args struct.  So if a server sends  
> too many device notifications in a callback, should the client  
> return an error or just process as many as it can?  If it does  
> return an error, should it still process the notifications?

I'm not sure what you mean by "too many" ..

It seems that a well behaved server would take other actions if  
DEVICEIDs needed to be changed en masse (recall all the LAYOUTS  
etc..) ..

 From a NFS client implementation POV i'd  process the array to  
completion.

Robert.

---

From: Benny Halevy <[email-masked]>
Date: Thu, 16 Oct 2008 15:48:53 +0200

>> return an error, should it still process the notifications?

The effective limitation should be derived from the negotiated
ca_maxrequestsize in csa_back_chan_attrs and the client should
be prepared to process any number of deviceid notifications that
fit in that maximum request size.

Should the server attempt to send a bigger request, the client
should return an NFS4ERR_REP_TOO_BIG error.

That said, I don't see CB_NOTIFY_DEVICEID's valid error returns
in section 15.3.  Callback operations and their valid errors

> I'm not sure what you mean by "too many" ..

Linux has an internal limit on the number of deviceid notifications.
Currently it's just pulled out of thin air and I think it should
be derived from ca_maxrequestsize.

In case the client is confused, or just lazy :)
it can purge all the devices it knows about.  This will always
cover the notified deviceid's (that the client knows about).

> DEVICEIDs needed to be changed en masse (recall all the LAYOUTS  

Right, yet the client should process the callback in full.

>  From a NFS client implementation POV i'd  process the array to  

Agreed.

Benny

---

From: Dean Hildebrand <[email-masked]>
Date: Thu, 16 Oct 2008 14:57:39 -0700

Ok, thanks.  Now we just need to fix in the spec:

Dean

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 16 Oct 2008 15:24:51 -0700 (PDT)

> b) Page 392, CB_NOTIFY_DEVICEID points to the wrong section.  It should

Dean,

I will take a look at this tomorrow and expect to ensure
this is fixed in the final RFC.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: "Mike Eisler" <[email-masked]>
Date: Sun, 19 Oct 2008 18:03:51 -0700 (PDT)

Here are proposed diffs:

Index: nfsv41_middle_errors.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_errors.xml,v
retrieving revision 1.70
diff -r1.70 nfsv41_middle_errors.xml
3082a3083,3100
>     <c>CB_NOTIFY_DEVICEID</c>
>     <c>
>       NFS4ERR_BADXDR,
>       NFS4ERR_DELAY,
>       NFS4ERR_INVAL,
>       NFS4ERR_NOTSUPP,
>       NFS4ERR_OP_NOT_IN_SESSION,
>       NFS4ERR_REP_TOO_BIG,
>       NFS4ERR_REP_TOO_BIG_TO_CACHE,
>       NFS4ERR_REQ_TOO_BIG,
>       NFS4ERR_SERVERFAULT,
>       NFS4ERR_TOO_MANY_OPS
>     </c>
>
>     <c />
>     <c />
>
>
Index: nfsv41_middle_op_mandlist.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_op_mandlist.xml,v
retrieving revision 1.6
diff -r1.6 nfsv41_middle_op_mandlist.xml
405c405
<       <c> <xref target="OP_CB_NOTIFY" /> </c>
---
>       <c> <xref target="OP_CB_NOTIFY_DEVICEID" /> </c>
Index: nfsv41_middle_proc_compound.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_proc_compound.xml,v
retrieving revision 1.19
diff -r1.19 nfsv41_middle_proc_compound.xml
145c145
<        PUTPUBFH (<xref target="OP_PUTROOTFH"/>) operations also set the
---
>        PUTPUBFH (<xref target="OP_PUTPUBFH"/>) operations also set the

-----------------------------------------------------------------

---

From: Benny Halevy <[email-masked]>
Date: Mon, 20 Oct 2008 11:00:03 +0200

Mike, this looks good.

Thanks,

Benny

---

From: Dean Hildebrand <[email-masked]>
Date: Mon, 20 Oct 2008 10:50:21 -0700

Looks good, thanks for the update.
Dean