Subject: [nfsv4] Block Layout and CB_SIZECHANGED

From: [email-masked]
Date: Thu, 13 Jul 2006 23:15:49 -0400

>   - People are still confused about what it does in the block's case.
>     David Black gave an example that helped some understand, others not.
>     I think it needs to be made very clear how this is not an
>     optimization but rather required for correctness.

For blocks, the need for CB_SIZECHANGED is caused by lazy evaluation
of COMMIT-based EOF changes.  The sequence of operations is the
following:

1) pNFS client takes out an extent from 32k to 64k, and writes data.
	It marks the written area as needing to be COMMIT-ed, but
	doesn't do the COMMIT.
2) Some other client uses SETATTR to truncates the file to be 4k in size.

The file is now 4k in size, but if the pNFS client does its COMMIT,
the file will erroneously grow to 64k in size.  Therefore, as part
of the SETATTR, the pNFS client has to be told about the new file
size.  The client abandons its commit for 32k-64k as a result of this
notification, and it *has* to be told about the new file size in
order to do so.

That's why at least the SETATTR case of CB_SIZECHANGED is needed for
correctness.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 14 Jul 2006 08:12:43 -0400

> That's why at least the SETATTR case of CB_SIZECHANGED is needed for

In NFSv4.1 all applications are required use some form of locking in the
above scenario, or else they are not guaranteed cache coherency. IOW:
those applications are not guaranteed "correctness" even in the case of
no pnfs.

Now at the IETF meeting, you appeared to imply that there was some issue
with the layout itself being modified by a SETATTR call (something about
a change of the state of the blocks "owned" by the client(?)). Could you
please explain again what it is about the layout that changes and why it
is that the client needs to be notified.

Cheers,
  Trond