Subject: RE: [nfsv4] pnfs last write offset

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

I'm fine with that too.

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.

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.

Benny

> -----Original Message-----
> 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
> 
> 
> 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: Garth Goodson <[email-masked]>
Date: Fri, 02 Dec 2005 11:13:29 -0800

> information it has about the file.

Exactly, and I really like this way of having the client report to the 
server what it wrote.

> field should be named accordingly: e.g. local_file_size.
I think we should think carefully before doing this.

I'm also not convinced that this field can be soley used for free space 
reclaimation as it does not give enough information back.  It only gives 
an offset, it does not tell where holes are etc.  I think that an 
appropriate layoutupdate structure may be better at conveying this 
information (especially in the blocks world).

But we should make the spec clear on this point.

-Garth

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 2 Dec 2005 14:14:45 -0500

> information it has about the file.

Right.

> 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.

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 2 Dec 2005 13:59:40 -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