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

"J. Bruce Fields" <> Sat, 02 October 2010 20:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CB6C3A6DDE for <>; Sat, 2 Oct 2010 13:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.594
X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j7PrIG542XFZ for <>; Sat, 2 Oct 2010 13:35:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 306FB3A6DB3 for <>; Sat, 2 Oct 2010 13:35:19 -0700 (PDT)
Received: from bfields by with local (Exim 4.71) (envelope-from <>) id 1P28oB-0006M7-2P; Sat, 02 Oct 2010 16:35:51 -0400
Date: Sat, 02 Oct 2010 16:35:51 -0400
To: "Erasani, Pranoop" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
From: "J. Bruce Fields" <>
Cc: Benny Halevy <>,
Subject: Re: [nfsv4] New version of sparse draft(draft-hildebrand-nfsv4-read-sparse-01.txt)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 02 Oct 2010 20:35:20 -0000

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