Subject: [nfsv4] LAYOUTCOMMIT and last_write_offset

From: Casey Bodley <[email-masked]>
Date: Fri, 7 Oct 2011 11:36:55 -0400

Tracking down a special test failure in our windows client has raised
an interesting question about LAYOUTCOMMIT and the size attribute for
file layouts.

I'm seeing a case where one thread sends a LAYOUTCOMMIT for the range
[0, N) while other threads are in the process of writing the range [N,
2N).  Because the LAYOUTCOMMIT gives last_write_offset=N-1, the server
truncates some of the data written past offset=N.

It appears that this requires some synchronization on the part of the client, to
a) delay WRITEs to data servers that would extend the file until it
receives the response to any LAYOUTCOMMIT that sets last_write_offset,
and
b) adjust or omit the new_last_offset of a LAYOUTCOMMIT when other
WRITEs to data servers are already in progress.

But given that section 12.5.4.2 (LAYOUTCOMMIT and size) of RFC 5661
states "the client MAY set no_newoffset to TRUE and provide an offset
that will update the file size," it seems that a file layout client
would be technically correct to send all LAYOUTCOMMITs with
no_newoffset=FALSE.  Can this burden of synchronization be relieved
under the assumption that a metadata server will always be able to
determine the last_write_offset for a given file layout on its own?

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 7 Oct 2011 08:48:11 -0700

inline ...
> [0, N) while other threads are in the process of writing the range [N,
^^^^^^^^

Do you mean [0, N - 1]?

> truncates some of the data written past offset=N.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

It shouldn't do that.

> that will update the file size,"

The spec goes on to say:

       For example, the
       file must not be truncated if the client presents a last write
       offset less than the file's current size.

If client wants to truncate a file, then it should use SETATTR to do so.
LAYOUTCOMMIT is not a vehicle for file truncation. It is a way for the
client to optimize the MDS's discovery of a lengthened file.

> it seems that a file layout client
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Casey Bodley <[email-masked]>
Date: Fri, 7 Oct 2011 12:03:15 -0400

>> truncates some of the data written past offset=N.

Ah, that's the bit I missed.  Thanks for the clarification.

---

From: "Benny Halevy" <[email-masked]>
Date: Sun, 9 Oct 2011 01:58:59 +0000

== what Mike said.

What server are testing against?

Benny

-----Original Message-----
From: "Mike Eisler" <[email-masked]>
Sender: [email-masked]
Date: Fri, 7 Oct 2011 08:48:11 
To: <[email-masked]>
Subject: Re: [nfsv4] LAYOUTCOMMIT and last_write_offset

inline ...
^^^^^^^^

Do you mean [0, N - 1]?

It shouldn't do that.

The spec goes on to say:

       For example, the

---

From: Casey Bodley <[email-masked]>
Date: Sun, 9 Oct 2011 16:09:33 -0400

Benny,
This was against an emc server.  I've reported the issue.