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

From: [email-masked]
Date: Tue, 20 Jun 2006 15:59:31 -0400

Does Dave really want to build the entire list of conflicting
operations for the RECALL_FSID case?  I don't have a problem
with an array to list the operations, but I also don't have a
good sense of what's going to happen in practice because to a
first approximation, HighRoad/FMP uses a single slot per file.

Another interesting question: Would a SLOTID_UNKNOWN value
also be useful to allow a server to not check for conflicting
operations at the cost of having the client always wait out
conflicts? It might be useful for RECALL_FSID on a busy
pNFS filesystem (or some other situation where the server
wants to tell the client "just do it").

Thanks,
--David 

> -----Original Message-----
> From: Talpey, Thomas [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 3:44 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: RE: [nfsv4] Sessions: Need reserved slotid values
> 
> 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.
> 
> At 03:25 PM 6/20/2006, [email-masked] wrote:
> >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: Wed, 21 Jun 2006 09:04:54 -0400

>operations for the RECALL_FSID case?  I don't have a problem

Well, the server certainly has the list handy. It's right in the per-session
slot table/DRC. With a small amount of checking the server can determine
exactly which cached operations apply.

Alternatively, the server can simply say "none" and let the client sort it
all out. This may involve the client attempting to ping the server in order
to flush in-flight operations from the TCP stream. Or, it may decide to
simply wait for a short time, if it believes it may have operations outstanding.

I am not against having a kind of faceless "more than one", but I don't see
why it's onerous on the server to provide the actual list, given the way a
session service is implemented. In fact, I wonder if the server couldn't just
put in a complete list of the session's outstanding ops, whether or not they
apply to the callback. The client doesn't really do anything different with
each one, it just wants to be sure it has seen the server's reply.

>conflicts? 

I don't think so, for the reasons I mention. Besides, if we provide the
value, don't you think most servers will simply take the easy way out
and use it? :-)

Tom.

>It might be useful for RECALL_FSID on a busy