Subject: RE: [nfsv4] Block Layout and CB_SIZECHANGED

From: [email-masked]
Date: Fri, 14 Jul 2006 11:21:49 -0400

> I'd argue that until you commit the layout, you are still in the
> situation where the data has not been written. You have not done the
> equivalent of a full NFSv4.0 unstable WRITE since a successful unstable
> write must update both the data _and_ the metadata in the server's cache.
> IOW the point at which the written data becomes visible to others is
> what matters, and that means after LAYOUTCOMMIT.

And if NFS were the only possible communication channel, I might agree,
but going back to my scenario (and inserting a couple of instances of
"[layout]" for clarification:

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

Suppose that the clients are in cahoots - there was an out-of-band
communication between them, and the SETATTR was supposed to throw
away the first client's writes (and some other data).  Having it
reappear because pNFS did something strange (first client does the
delayed LAYOUTCOMMIT after the SETATTR) would be peculiar, and
to my mind, forcing the application above NFS to fflush() or the
equivalent (to force an earlier LAYOUT COMMIT) before the out-of-band
communication is tantamount to admitting that there is a problem here
but we're going to force applications to fix it.  This is an NFS vs.
pNFS behavior difference that I'd prefer to eliminate.

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

> > But David is not talking about cached writes but writes done to 
> > the data server which have not been LAYOUTCOMMITed.  There is no 
> > non-pnfs equivalent of that.
> > 
> > The closest I can come is unstable writes done to the server
> > which have not been COMMITed.  In this case a truncate is effective
> > without locking.  You do the the COMMIT and the file not extended.
> > 
> > How you judge this case depends on what analogies you make.  Is
> > writing to the data server more like putting things in your cache
> > or it more like doing an unstable write?  I'd argue that the latter
> > is a more appropriate analogy.
> 
> I'd argue that until you commit the layout, you are still in the
> situation where the data has not been written. You have not done the
> equivalent of a full NFSv4.0 unstable WRITE since a successful unstable
> write must update both the data _and_ the metadata in the server's cache.
> IOW the point at which the written data becomes visible to others is
> what matters, and that means after LAYOUTCOMMIT.
> 
> Cheers,
>   Trond

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

---

From: [email-masked]
Date: Fri, 14 Jul 2006 11:21:49 -0400

Thanks,
--David