Subject: Re: [nfsv4] pnfs last write offset

From: Benny Halevy <[email-masked]>
Date: Wed, 01 Mar 2006 20:54:36 -0800

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

---

From: Dean Hildebrand <[email-masked]>
Date: Mon, 06 Mar 2006 12:33:22 -0500

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:
> 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
>
>> Or maybe we want the field to be one byte beyond the offset of the 
>> last byte you wrote.
>>
>> From: Halevy, Benny [mailto:[email-masked]] Sent: Friday, 
>> December 02, 2005 1:11 PM

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