Re: [nfsv4] question on bulk recall text

["Halevy, Benny" <[e-mail]>]

> 
> 
> From: [e-mail] on behalf of Mike Eisler
> Sent: Thu 2010-10-14 00:33
> To: [e-mail]
> Subject: Re: [nfsv4] question on bulk recall text
> 
> On Tue, October 12, 2010 11:37 am, Trond Myklebust wrote:
> > On Tue, 2010-10-12 at 13:43 -0400, Benny Halevy wrote:
> >> On 2010-10-12 12:59, Trond Myklebust wrote:
> >> > On Tue, 2010-10-12 at 12:19 -0400, Fred Isaman wrote:
> >> >> The text for bulk recalls in 12.5.5.2.1.5 seems flawed:
> >> >>
> >> >>    Once a CB_LAYOUTRECALL of LAYOUTRECALL4_ALL is sent, the server
> >> MUST
> >> >>    NOT allow the client to use any layout stateid except for
> >> >>    LAYOUTCOMMIT operations.  Once the client receives a
> >> CB_LAYOUTRECALL
> >> >>    of LAYOUTRECALL4_ALL, it MUST NOT use any layout stateid except
> >> for
> >> >>    LAYOUTCOMMIT operations.
> >> >>
> >> >> (similarly for LAYOUTRECALL4_FSID)
> >> >>
> >> >> My question: what stateid does the client use to send the required
> >> LAYOUTRETURN?
> >> >
> >> > LAYOUTRETURN with a LAYOUTRETURN4_FSID or a LAYOUTRETURN4_ALL argument
> >> > doesn't take a stateid.
> >>
> >> Right, but if the client wants to return individual layouts
> >> in the process the question is still valid.
> >> One reason to do that is to show progress while the client
> >> is flushing its caches.d 
> >
> > LAYOUTCOMMIT should suffice to show progress, whereas LAYOUTRETURN with
> > a LAYOUTRETURN4_FILE appears to be explicitly prohibited by the spec
> > (and not just in the text that Fred quotes).
> 
> Correct, no point in a bulk recall if you can't have a bulk return.
> 

True, and the last layoutreturn in response to the layoutrecall callback must be one.
But can't the client send RETURN_FILE layoutreturns voluntareely in the meanwhile
using the layout stateid is has in hand?.
I may need to be reminded at the exact test in the spec the prohibits that as Trond said...
 
Benny