Subject: [nfsv4] Open items in NFSv4.2

From: Thomas Haynes <[email-masked]>
Date: Wed, 16 Apr 2014 13:04:33 -0700

I'm in the process of building an open issues list with the 4.2 spec and
one of the things I've come across is the interaction between READ_PLUS
and ADHs.

1) Ignoring the whole issue of whether ADHs should be in the spec
or not, I want to tackle the other issue of what does a client do if it does
not (and never will) support an arm of READ_PLUS?

I.e., the client informs the server it wants to get holes back instead of data.
But now it is exposed to having to also receive ADHs. In the future, it might
get back 64 bit I/O or any new arm.

We can easily mark the request to state which arms the client is able to
support:

struct READ_PLUS4args {
        /* CURRENT_FH: file */
        stateid4        rpa_stateid;
        offset4         rpa_offset;
        count4          rpa_count;
        data_content4   rpa_what;
};

The server can then determine whether it can return an arm or not.

In the case of ADHs, the intent was that even if the client did not support
ADHs, we could avoid the transmission of the data across the wire
by allowing the client to expand the ADH to an in-memory representation.

If the client never dirties the corresponding blocks, they never get written
back to the server. Thus only ADH blocks which get instantiated get sent
back to the server. I.e., the client does not need to remember the fact that
it got an ADH on the wire.

2) That leaves open how the client would then need to interact with SEEK.
Take a client that has no plans to implement ADHs. It does a
SEEK(NFS4_CONTENT_HOLE). The server determines that there is
an ADH followed by data.  A file is either going to have normal holes
or ADH, mixing the two does make sense. So does the server tell the
client that there is a hole encountered and then use sr_contents to
differentiate the two?

Likewise for a SEEK(NFS4_CONTENT_APP_DATA_HOLE)?

3) In draft-23 *, I split WRITE_PLUS into WRITE_HOLE and WRITE_SAME.
In the past, Christoph has proposed that the WRITE_SAME not create a
hole (of the ADH variety), but actually write the blocks out. This would solve
both issues above, at the cost of WRITE_SAME becoming more inclined
to be asynchronous and having to transfer data.

Notes:

* Waiting for IETF to authenticate my new email address. Until then, you can
do a:

$ git clone [email-masked]:loghyr/NFSv4.2.git

to get a working copy.

---

From: Christoph Hellwig <[email-masked]>
Date: Thu, 17 Apr 2014 21:44:52 +0200

> to be asynchronous and having to transfer data.

I don't care if the server actually writes the data out, the point is to
declare the protocol so that the semantics are as if the server wrote it
out.  Assuming we have a server that can efficiently store the ADHs it
would implement it's write path as is, and just expand them at READ time.

---

From: David Noveck <[email-masked]>
Date: Thu, 17 Apr 2014 16:09:44 -0400

> hole (of the ADH variety),

Maybe I didn't understand Christoph correctly, but my interpretation of what
Christoph was saying is that servers would not be required to remember
the fact that a WRITE_SAME had been done.  The server would not need to
remember that because there would be no need to return ADH"s on
READ_PLUS.  Essentially, ADH"s would go away as far as being returned
on read and be would replaced by WSA's (written-same areas :-) which
would not be part of the protocol.

> but actually write the blocks out.

That would be  a likely implementation but a server would be free to
remember
that an area had been written-same instead of actually expanding the data
when written.  In this case the server would expand the data at READ time.

>This would solve both issues above,

These issues being:

   1. That the other approach, instead of "allowing the client to expand
   the ADH to an in-memory representation" essentially forces them to do
   so, which, arguably at least, makes ADH support on the client essentially
   mandatory, if the server supports them.  I don't think that is workable.
   2. That it's very confusing to seek to a hole when the protocol
   complicates the data model for files to include multiple species of holes.

> at the  cost of WRITE_SAME becoming more inclined to be asynchronous and

Server implementations that expanded the data at write time would become
more inclined to be asynchronous.

Server implementations that didn't (and deferred expansion to READ time)
would not.

One could argue that there would be very few of the latter.  Note that
there would likely be very few servers that support ADH"s if the protocol
required the server/filesystem to remember ADH locations.

Remembering WSA's is a choice few will make.  For the same reasons,
remembering ADH"s is likely to be similarly uncommon  The difference is
that you can support WRITE_SAME without remembering WSA's but you can't
support ADH"s without remembering them.

> having to transfer data.

In the case of reading a written-same area.

On Wed, Apr 16, 2014 at 4:04 PM, Thomas Haynes <
[email-masked]> wrote:

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