Re: [nfsv4] New version of sparse draft(draft-hildebrand-nfsv4-read-sparse-01.txt)

["J. Bruce Fields" <[e-mail]>]

Their current proposal is mainly just an optimization to allow returning
long strings of zeroes to clients in read requests.  (Servers may be
using file allocation information to identify long strings of zeroes
efficiently, but that's an implementation detail.)

This isn't about allocation, or metadata--it's just a minor incremental
improvement to READ.

The proposal decreases the size of read responses, and may decrease the
number of read requests as well in the case of a sequential reader.

As such, agreed: it doesn't allow a lot of optimizations that an
allocation map would.

It's also simpler than an allocation-map operation:

	- It's just a read, so we already know the semantics.
	- It never performs worse than ordinary read.

You may well be right that it simply isn't worth the trouble, whereas a
GET_HOLE_MAP operation would be.

But I think your proposal is sufficiently different that it should be a
separate proposal.  Beats me whether it would be a competitor to this
one, or complementary to it.

A few questions about a map:

	- What is its lifetime?  Will it be a recallable object like a
	  layout, or does the client invalidate it normally whenever it
	  would invalidate its data cache?
	- Does requesting the block map break write delegations, or (on
	  servers that support atime) update the atime?
	- How does a request for a map they interact with mandatory
	  locks?

--b.