Subject: [nfsv4] Some discussion items for the sparse I/O in NFSv4.2 I-D

From: Thomas Haynes <[email-masked]>
Date: Mon, 18 Apr 2011 13:57:17 -0500

In the Thursday meeting, I'm going to want to settle these open issues:

Assumptions:
------------

1) Creating a pattern is a rare occurrence.

2) Pattern punching is a rare occurrence.

Issues:
-------

1) Do we want to be able to set/get an array of patterns/holes?

We can return a short read whenever we have a transition from
pattern to data.

If we store multiple patterns, then we change this to state
we also return a short read when we transition from pattern
A to pattern B.

NOTE: I think I am the only proponent of the array idea.
Both Dean (in his I-D) and David Black have expressed
the short read approach.

2) If a pattern extends past the requested read size, do we
return all of the pattern or just up to the requested size?

In this case, it might be of benefit to return to the client
that the pattern extends much farther.

3) Likewise, if a read starts after the beginning of the
pattern, do we return the start of the pattern or the
start of the request?

Note that with a repeating pattern (i.e., without the
enterprise app logical blocks), this is easy to
accomplish. With the logical blocks, we either have to
align on those blocks or mandate that the client has to
handle getting back a pattern which can start before
the requested range.

4) Do we want to limit a file to a single pattern?

We would have to add complexity to enforce this within
the protocol. And as the server needs to already be
prepared to store multiple patterns per file, it
already encompasses the complexity needed to store
multiple patterns.

5) Do we want to discuss minimum pattern size?

I.e., "Hole Threshold" in the current draft.

This sounds like a server implementation issue.

What needs to happen is that we stress that all writes
are advisory and the server decides whether to store
a pattern as a pattern or as data. The client should never
expect a read to return a pattern instead of data.

6) We've had a proposal to have the union represent
patterns, holes, and data.

We can handle the complexity in the XDR, but does this
open the door for an implementation
to not handle all 3 cases?

7) Does the pattern only occur once in the block or
at every location?

Every location.

8) In the pNFS case, do the pattern writes go to the
DS or the MDS?

The patterns are metadata information.

If we state that WRITE_PATTERN goes to the MDS, then
we avoid the issue of the DS having to communicate
patterns back to the MDS. We are still in the situation
that the MDS needs to communicate holes to the DSes.

8A) If the writes go to the MDS, should this cause
layouts to be recalled? I.e., is this a subset of
async I/O to the MDS?

8B) Are there race conditions between the MDS getting
pattern writes and the DS getting data writes?

9) Do we want to allow a PATTERN_MAP operation which
would allow a client to see where patterns occur versus
data?

Note: If we supply this functionality, it becomes
trivial for the DSes to call a similar function on
the Control Protocol. But then again, this is an
implementation consideration. :->

10) We need to explicitly call out what happens if
a NFSv4.x, NFSv3, or NFSv2 READ encounters a pattern.

I.e., data is returned.

If the client wants a shot at getting the pattern, it
needs to invoke READ_PLUS.

11) Do we want to support large reads and writes?