Subject: RE: [nfsv4] pnfs last write offset

From: [email-masked]
Date: Mon, 6 Mar 2006 12:49:34 -0500

At least in the block/volume case, offset + length may
not always = last_write_offset.  This is due to the block-based
granularity of layouts in this approach.  So the client may
be committing a layout at offset 0 of two blocks (say 4k each
so length is 8192), but only wrote as far as byte 6144.
For this reason, I would like to keep all three.
-Steve  

> -----Original Message-----
> From: Dean Hildebrand [mailto:[email-masked]] 
> Sent: Monday, March 06, 2006 12:33 PM
> To: Benny Halevy
> Cc: Goodson, Garth; Welch,Brent; Noveck,Dave; [email-masked]
> Subject: Re: [nfsv4] pnfs last write offset
> 
> Here's the current layoutcommit arg structure:
> struct LAYOUTCOMMIT4args {
>              /* CURRENT_FH: file */
>              clientid4               clientid;
>              offset4                 offset;
>              length4                 length;
>              length4                 last_write_offset;
>              newtime4                time_modify;
>              newtime4                time_access;
>              pnfs_layoutupdate4      layoutupdate;
>      };
> 
> Are offset, length, and last_write_offset all necessary?  Is 
> it possible 
> for offset + length != (last_write_offset + 1).  If they are always 
> equal, should we just delete last_write_offset?  The document doesn't 
> seem to get into this overlap is info.
> Dean
> 
> Benny Halevy wrote:
> 
> > I'm raising the following issue again since I understood from Garth 
> > Goodson that we haven't agreed on the solution yet...
> >
> > Reminder:
> > currently the i-d says the following:
> >    The "last_write_offset" field specifies the offset of 
> the last byte
> >    written by the client previous to the LAYOUTCOMMIT.
> >
> > One problem with this definition arises when the client haven't 
> > written to the object at all.  Sending the value 0 means that the 
> > client wrote one byte at offset zero and might cause the 
> server to set 
> > the file length to 1.
> >
> > I suggest we adopt Dave Noveck's proposal below to set the field to 
> > one byte beyond the offset of the last byte the client wrote, or to 
> > zero if the client have not written to the file (it may 
> still want to 
> > send layout commit, e.g. for freeing provisionally 
> allocated blocks).
> >
> > Benny
> >
> > On Fri, 2 Dec 2005 13:32:16 -0500, Noveck, Dave wrote:
> >
> >> Or maybe we want the field to be one byte beyond the offset of the 
> >> last byte you wrote.
> >>
> >> Maybe this would be a problem if you are writing a byte at offset
> >> 0xffffffffffffffff but if you did the size of the file wouldn't
> >> be representable in v4 anyway.
> >>
> >> -----Original Message-----
> >> From: Halevy, Benny [mailto:[email-masked]] Sent: Friday, 
> >> December 02, 2005 1:11 PM
> >> To: Goodson, Garth; Welch, Brent; Zelenka, Jim; 'David 
> Black' (E-mail)
> >> Cc: [email-masked]'
> >> Subject: [nfsv4] pnfs last write offset
> >>
> >>
> >> draft-ietf-nfsv4-pnfs-00.txt says:
> >>    The "last_write_offset" field specifies the offset of 
> the last byte
> >>    written by the client previous to the LAYOUTCOMMIT.  
> Note: this value
> >>    is never equal to the file's size (at most it is one 
> byte less than
> >>    the file's size).  The metadata server may use this 
> information to
> >>    determine whether the file's size needs to be updated.  If the
> >>    metadata server updates the file's size as the result of the
> >>    LAYOUTCOMMIT operation, it must return the new size as 
> part of the
> >>    results.
> >>
> >> What should the client set this to if it never wrote to the file
> >> and issues LAYOUTCOMMIT e.g. to free up provisionally allocated
> >> blocks?
> >>
> >> A last_write_offset value of 0 means that the file has 1 
> byte written
> >> to it so maybe last_write_offset should be of type 
> newsize4 rather than
> >> length4.
> >>
> >> Benny
> >>
> >> _______________________________________________
> >> nfsv4 mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/nfsv4
> >
> >
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> >
> 
> -- 
> Dean Hildebrand
> Ph.D. Candidate
> University of Michigan
> 
> 
> _______________________________________________
> 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: Benny Halevy <[email-masked]>
Date: Mon, 06 Mar 2006 20:13:51 +0200

This is true for objects as well as we need the offset and length to 
identify
the capabilities associated with this part of the layout while the last
write offset might not even be in this range.

Benny

---

From: Dean Hildebrand <[email-masked]>
Date: Mon, 06 Mar 2006 13:24:50 -0500

In this case,
a) we should put something in the spec about Steve and Benny's comments
b) Change the meaning of last_write_offset to be (last byte offset + 
1).  My only worry is that it will be confusing by having the word 
offset in the name, can we change the name? Maybe something like 
end_of_write?
Dean

Benny Halevy wrote:

>>> From: Dean Hildebrand [mailto:[email-masked]] Sent: Monday, 
>>> March 06, 2006 12:33 PM
>>> To: Benny Halevy
>>> Are offset, length, and last_write_offset all necessary?  Is it 
>>> possible for offset + length != (last_write_offset + 1).  If they 
>>> are always equal, should we just delete last_write_offset?  The 
>>> document doesn't seem to get into this overlap is info.
>>> Dean
>>>
>>> Benny Halevy wrote:
>>>
>>>   
>>>

-- 
Dean Hildebrand
Ph.D. Candidate
University of Michigan