Subject: RE: [nfsv4] pnfs last write offset

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 6 Mar 2006 13:43:37 -0500

Shouldn't the "last_write_offset" be of type offset4, not length4?  A
small matter, most likely.

		Craig 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, March 06, 2006 12:50 PM
> To: [email-masked]; [email-masked]
> Cc: Goodson, Garth; [email-masked]; Noveck, Dave; [email-masked]
> Subject: RE: [nfsv4] pnfs last write offset
> 
> 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
> 

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

---

From: Benny Halevy <[email-masked]>
Date: Mon, 06 Mar 2006 20:50:21 +0200

>small matter, most likely.
Yes, you're right.
Benny

---

From: Garth Goodson <[email-masked]>
Date: Mon, 06 Mar 2006 11:01:17 -0800

I'm wondering if it might just be easier/cleaner/less confusing to make 
this argument switched on a bool (like newtime4).  If the bool is true 
use the value as a byte offset (no confusion), if false, there is no 
value to be used.  This with a clarification in the text as to when the 
bool/offset MUST be set and when it need not be set should be sufficient 
and might help us avoid confusion over a variable that is 'one more than 
the last byte offset written'.

I can also add some text of the type Dean suggested in clarifying this 
matter, as well I can change the lenght type to offset type...

-Garth

Benny Halevy wrote:
>>> 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.

---

From: Benny Halevy <[email-masked]>
Date: Mon, 06 Mar 2006 21:05:44 +0200

Garth Goodson wrote:

> I'm wondering if it might just be easier/cleaner/less confusing to 
> make this argument switched on a bool (like newtime4).  If the bool is 
> true use the value as a byte offset (no confusion), if false, there is 
> no value to be used.  This with a clarification in the text as to when 
> the bool/offset MUST be set and when it need not be set should be 
> sufficient and might help us avoid confusion over a variable that is 
> 'one more than the last byte offset written'.

I'm good with that
(see my original proposal from 12/2/2005 down below :-)

Benny

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 17 Mar 2006 20:44:56 -0600

I have created the following issue to track this:

http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue9