Subject: [NFSv4] Hints for client on LAYOUTRECALL

From: [email-masked]
Date: Tue, 8 Aug 2006 17:07:40 -0400

Hi All---
We have recently come to consensus that the CB_SIZECHANGED
callback should be dropped and Benny has proposed the necessary
changes.  On a related note, I made a suggestion about adding
hints to the CB_LAYOUTRECALL callback which drew little feedback.
I'm starting a separate thread on the topic to see if there
is any interest out there.

The basic issue is how can the client avoid an unnecessary
flush and LAYOUTCOMMIT when a file is truncated?  Without
CB_SIZECHANGED, upon receiving a truncate request the server (at
least for the block/volume layout) will send a CB_LAYOUTRECALL
for the portion of the layout beyond the new end of file.  As
the protocol currently stands, the client has no way of knowing
whether this LAYOUTRECALL is the result of a truncate, or simply
a competing writer.  The usual response to the LAYOUTRECALL by
the client is to flush the dirty data covered by the LAYOUT,
issue a LAYOUTCOMMIT, followed by a LAYOUTRETURN.  But in the
truncate case, the blocks written and committed by the client
will be immediately truncated by the server as soon as it
receives the LAYOUTRETURN.   

If the CB_LAYOUTRETURN contains a hint indicating that the
callback is the result of a truncate, the client can choose to
simply clobber the cached data and return the layout without
commit.  This saves processing time at the client, the server,
and the data server.

I notice that CB_LAYOUTRETURN already contains a flag argument,
"layoutchanged".  We could convert this argument from a boolean
to a bit mask called "hints", with two defined values:
"layoutchanged" and "truncate".

Any opinons?  If there is interest in this idea I can create
an issue and a detailed proposal...

-Steve

------------------------------------------------------------
Stephen Fridella                            ph: 508-305-8512
EMC NAS Advanced Development             sfridell at emc com

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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 08 Aug 2006 23:24:23 -0400

> commit.  This saves processing time at the client, the server,

That would be incorrect behaviour w.r.t. the NFS caching model. A
truncate by another client should _not_ cause cached data to be
clobbered.

Cheers,
  Trond

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 8 Aug 2006 23:26:27 -0500

> truncate by another client should _not_ cause cached data to be

I agree.  This is a change in behavior from what exists today
at the NFS client.  It is best left as it is.

Spencer