Subject: RE: [nfsv4] Issue 21: pnfs EOF handling

From: [email-masked]
Date: Tue, 27 Jun 2006 18:11:51 -0400

> -----Original Message-----
> From: Garth Goodson [mailto:[email-masked]] 
> Sent: Tuesday, June 27, 2006 4:51 PM
> To: fridella, stephen
> Cc: [email-masked]
> Subject: Re: [nfsv4] Issue 21: pnfs EOF handling
>

<snip> 

>
> Is this too restrictive for some implementations (i.e., impose 
> unnecessary delays when the backend system can handle the 
> changes)?  My 
> concern arises over the MUST send CB_SIZECHANGED and SHOULD 
> NOT respond 
> to the SETATTR until all responses have been received (I 
> guess it is a 
> SHOULD NOT rather than a MUST NOT).  Remind me why we need to 
> wait for 
> the CB replies.
> 

The idea was that the server should be sure that the clients
have a consistent view of the file size before allowing the
truncate to succeed. I suppose the problem is that different
layout types have different requirements for the consistency
of file size, with the file layout type having the loosest
requirements of all.  I don't mind making this a layout-type
specific requirement.  The question is, what do we say in the
generic spec?  Perhaps we could say something like:

Depending on the requirements of the storage protocol, the
server MAY need to ensure that all clients have a consistent
view of the file size before allowing the SETATTR to succeed.
If so, the server MAY need to delay processing the SETATTR
until receiving responses to the associated CB_SIZECHANGED
and CB_LAYOUTRECALL messages that it has sent to clients.
The precise details of when the server can process the
SETATTR are described in the layout-specific specifications.

> I also want to bring up something else that Spencer brought 
> up earlier. 
>   It went something like this:
> 
> 1) SETATTR that truncates file arrives
> 2) Server sends out CB_SIZECHANGED, and DELAY error to setattr caller
> 3) Setattr caller never retries SETATTR, but CB has been sent out
> 
> I'm not sure how to work around this.  Is this a problem -- 
> or is it ok 
> that the client can confuse other clients?
> 
> -Garth
> 

It does seem like a problem.  I have to think some more
about it.  The danger is that a client will believe that
its LAYOUT is beyond the end of file, and hence not committed,
when in fact, it is actually fine (since the truncate never
occurred).  In this case the cost is the client re-committing
a LAYOUT unnecessarily.  Hopefully the server is tolerant
of this case.  Is it possible to require that the server
not return DELAY?

--Steve

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

---

From: Garth Goodson <[email-masked]>
Date: Thu, 29 Jun 2006 09:18:15 -0700

> SETATTR are described in the layout-specific specifications.
I do prefer something like this.  It gives a bit more latitude and 
allows for layout-specific details to be handled separately.

> of this case.  Is it possible to require that the server
I'm not an expert on the DELAY rules.  However, it seems that if the 
server needs to block for a possibly long period of time, waiting for 
all the callback responses, then it must send out a DELAY message.  The 
spec says: 'The server initiated the request, but was not able to 
complete it in a timely fashion...'  Maybe others can chime in here on 
how to handle this.

-Garth