NFSv4.2 issues list

On Thu, Apr 24, 2014 at 12:00:18PM -0700, Tom Haynes wrote:
> 1) space_reserved flag - what does it mean now that reservations
>    are byte ranges?
>
>    See the recent chatter on the WG.

Here is my proposal to address this issue:

The terminology of allocated vs unallocated blocks in READ_PLUS and SEEK
is confusing as there it doesn't have a whole lot of meaning for a remote
filesystem, especially if it sits on top of complex COW or snapshotting
filesystem.  Even if a block is allocated writes into it might return NOSPC,
and even if it's not allocated it might have space reserved making writes
into it semaingless.

So intead of returning the allocated/unallocated information return the
reservation status of a hole or data block range, as that actually is
meaninful to the client.  For a traditional, simple Unix filesystem the
two are equivalent, but the the strictly defined meaning of reserved
vs unreserved actually does matter for more complex server implementations.

Because we want the answert to be exact but servers might not always be able
to get the exact information add a third possible unknown state to the
reservation status.  This should also help with the earlier discussions if
the allocation status should be exact or a hint.

Signed-off-by: loghyr <loghyr@primarydata.com>
Little bit of clean-up on space reserved
NFSv4.2 issues list

On Thu, Apr 24, 2014 at 12:00:18PM -0700, Tom Haynes wrote:
> 2) Do we want to maintain punch hole versus write zeros OR do we
>    want to leave that to the server?
>
>    We added this, but is it realistic?
>
>    Also, is it a hint or mandatory?
>
>    Either way, I want us to revisit it.

Hole punching vs zeroing is an important difference in semantics, and it
becomes even more important with the strictly defined space reservation
semantics.

I've attached a patch (ontop of my previous patch in this thread) which
tries to address these issues by splitting them up into different operations.

Zeroing a file of parts of it can be done with the WRITE_SAME operation
in the current ADB form - an ADB without pattern or block number will
simply zero the file, so that part of WRITE_HOLE is properly replaces by
WRITE_SAME already, I've just added an example section for it.

The hole punch now becomes a simple metadata operation mirroring ALLOCATE,
thus termed 'DEALLOCATE', and it now actually drops the reservation, which
is the only sensible semantic for it to implement the sort of hole punches
clients expect.  It also is purely synchronous as it just is a generalization
of SETATTR to a smaller size, which servers must handle synchronously already.

Signed-off-by: loghyr <loghyr@primarydata.com>
Cleanup after DEALLOCATE