Subject: RE: [nfsv4] Sessions: Need reserved slotid values

From: [email-masked]
Date: Tue, 20 Jun 2006 15:25:10 -0400

Tom,

> Can you walk me through the need for "multiple"? I am not
> readily seeing how a delegation or layout recall can depend
> on more than one client request. Maybe I am just being dense.

Layout operations specify a range, e.g.:
	--> LAYOUTGET (0-1MB for READ)
	--> LAYOUTGET (2MB-3MB for WRITE)
	<-- CB_LAYOUTRECALL (the whole file)

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Talpey, Thomas [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 3:05 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [nfsv4] Sessions: Need reserved slotid values
> 
> I definitely agree on the need for a "none" indicator in the
> dependent-op reference. I'll provide text.
> 
> Can you walk me through the need for "multiple"? I am not
> readily seeing how a delegation or layout recall can depend
> on more than one client request. Maybe I am just being dense.
> 
> Tom.
> 
> At 02:50 PM 6/20/2006, [email-masked] wrote:
> >I'm starting to work through the issues around applying
> >sessions to potential pNFS races (19) and have run into
> >a couple of problems with CB_SEQUENCE:
> >
> >(1) The referring slotid and sequenceid are supposed to
> >	be optional (cf. section 9.5.3), but the text doesn't
> >	say how to determine whether they're present vs. absent.
> >
> >(2) For pNFS, there could be multiple conflicting operations
> >	that have to be referred to, but CB_SEQUENCE can only
> >	carry one slotid/sequence reference.
> >
> >I think this can be fixed with a couple of reserved slotid
> >values, SLOTID4_NONE, and SLOTID4_MULTIPLE - which could
> >be 0xffffffff and 0xfffffffe .  pNFS does need to distinguish
> >MULTIPLE from NONE, as NONE is the only case in which a client
> >can immediately process a recall.
> >
> >I'll open this up in the issue tracker as well - I think this
> >is Tom's to resolve.
> >
> >Thanks,
> >--David
> >----------------------------------------------------
> >David L. Black, Senior Technologist
> >EMC Corporation, 176 South St., Hopkinton, MA  01748
> >+1 (508) 293-7953             FAX: +1 (508) 293-7786
> >[email-masked]        Mobile: +1 (978) 394-7754
> >----------------------------------------------------
> >
> >
> >_______________________________________________
> >nfsv4 mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> 
> _______________________________________________
> 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: "Talpey, Thomas" <[email-masked]>
Date: Tue, 20 Jun 2006 15:44:03 -0400

Ok, whole-file recalls. Got it.

How about an alternative proposal - make the referring { sequenceid,
slotid } pair in the CB_SEQUENCE a counted array? (this is Dave Noveck's
suggestion).

Then, an empty array means "none", or N entries exactly name any
outstanding operations. The sequencing rules handle ops that are still
in flight to the server so the client can completely disambiguate any
races before replying, just as in the single-op case.

I think this would solve the "multiple" case even better?
 
Tom.