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

["Erasani, Pranoop" <[e-mail]>]

Bruce,

Thanks for getting back.

> 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.

That's one interpretation. But, having to deprecate READ to provide this
feature
doesn't seem like a minor feature to me.

I don't read it as just an optimization. The stated goal seems to be
applicable all kinds of access patterns (i.e., it doesn't mention that
the algorithm is efficient for sequential pattern only).

The document says:

   This document extends the NFSv4.1 protocol to support efficient
   reading of sparse files.  The number of sparse files is growing in
   the data center, most notably due to the increasing number of virtual
   disk images.  This simple extension provides an easy and efficient
   way for administrators to copy and manage these files without wasting
   disk space or transferring data unnecessarily.

> 
> 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.

Great. We agree on the first point.

> 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.

I started with an intent to complement it, as I didn't see that the
current
proposal addresses many cases that I list below.

Basically, What are the requirements that we are trying to address with
this
proposal and what can we do to complete it to be beneficial to wider
range of
clients and servers.

> A few questions about a map:

Thanks for asking the questions.

I didn't myself think through the semantics of the hole map. So,
let's put the below questions in abeyance for a minute and address
my questions about requirements for the proposal by Dean. I promise
to come back with answers once I see that there is some direction on
whether the requirements need to be extended or whether another proposal
is warranted.

> 
> 	- 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?

For now, I feel that it has to be the latter. Similar to ctime
invalidation 
that this proposal warrants.

- Pranoop

> 	- 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.