Subject: [nfsv4] pnfs last write offset

From: "Halevy, Benny" <[email-masked]>
Date: Fri, 2 Dec 2005 13:11:24 -0500

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 2 Dec 2005 13:32:16 -0500

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

Benny

---

From: "Halevy, Benny" <[email-masked]>
Date: Fri, 2 Dec 2005 14:25:05 -0500

Yeah, total_write_size and your description is better than
local_file_size.

Benny

> From: J. Bruce Fields [mailto:[email-masked]]
> Sent: Friday, December 02, 2005 9:15 PM
> To: Halevy, Benny
> Cc: 'Noveck, Dave'; Goodson, Garth; Welch, Brent; Zelenka, Jim; 'David
> Black' (E-mail); [email-masked]
> Subject: Re: [nfsv4] pnfs last write offset
> 
> 
> On Fri, Dec 02, 2005 at 01:39:56PM -0500, Halevy, Benny wrote:
> > I think that the field was defined as such to stress the
> > fact that the client is not setting the file's length but
> > rather it's just reporting what's the highest offset it
> > wrote to and server should determine the new length
> > of the file based on these reports and possibly other
> > information it has about the file.
> 
> Right.
> 
> > If we're going the way you proposed than the client
> > is sending its local notion of the file size, hence the
> > field should be named accordingly: e.g. local_file_size.
> 
> I'd probably assume that the client's "local notion of the file size"
> refers to what it currently thinks the file size is--maybe whatever it
> cached from its most recent getattr request.
> 
> But it's true that the field would be more obviously one and not
> zero-based if it was described as a length or size instead of 
> an offset.
> The special interpretation of zero would be obvious then too. 
>  How about
> "total_write_size"?
> 
> For text, you could use something like:
> 
> 	The "total_write_size" field gives the length of the initial
> 	segment of the file containing all the bytes this client has
> 	written previous to the LAYOUTCOMMIT.  Thus this field is zero
> 	if and only if the client has not written to the file, and in
> 	the case where the client's writes are the only factor
> 	determining the size of the file, "total_write_size" is equal to
> 	the new file size.  More generally, the metadata server may use
> 	this information to determine whether and how to update the
> 	file's size.  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.
> 
> The only remaining confusion is that if you missed the 
> "initial segment"
> language it would be tempting to report "1" as total_write_size in the
> case of a client that wrote one byte to offset 100 of a file.  But I
> suppose we can't hope to communicate everything in the field name....
> 
> --b.
> 
> > Benny
> > 
> > > From: Noveck, Dave [mailto:[email-masked]]
> > > Sent: Friday, December 02, 2005 8:32 PM
> > > To: Halevy, Benny; Goodson, Garth; Welch, Brent; Zelenka, 
> Jim; 'David
> > > Black' (E-mail)
> > > Cc: [email-masked]
> > > Subject: RE: [nfsv4] pnfs last write offset
> > > 
> > >

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 2 Dec 2005 15:12:49 -0500 (EST)

One question and a comment, sorry if they are obvious:

1)
What provisional space are you freeing if you haven't written to the file?
Is the client saying it no longer is going to use the provisional space,
in which case maybe it should return that part of the layout?  If you free
provisional space, how can the layout still be valid?  I'm just curious
about the use case here as I'm interested in what you guys are doing with
the pNFS ops.

2) Trond and I were talking about some odd truncate scenarios with the
lastbytewritten field.
s1) Client A believe the file is 20 bytes.  Client retrieves a layout for
and writes to bytes 10-14.
s2) Client B truncates the file to 12 bytes.
s3) Client A performs LAYOUTCOMMIT with lastbytewritten=14 (although it
still believes the file is 20 bytes)

In this scenario, it would be best for the server to update the file size
to 15.  If lastbytewritten was changed to local_file_size, it would be set
to 20, which is wrong.

Dean

On Fri, 2 Dec 2005, Halevy, Benny wrote:

> I'm fine with that too.
> > To: Halevy, Benny; Goodson, Garth; Welch, Brent; Zelenka, Jim; 'David
> > Black' (E-mail)
> > Cc: [email-masked]