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

Dean Hildebrand <seattleplus@gmail.com> Thu, 30 September 2010 19:23 UTC

Return-Path: <seattleplus@gmail.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D893A6E7A for <nfsv4@core3.amsl.com>; Thu, 30 Sep 2010 12:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KndI5nHNvwzd for <nfsv4@core3.amsl.com>; Thu, 30 Sep 2010 12:23:17 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id A6D3C3A6E71 for <nfsv4@ietf.org>; Thu, 30 Sep 2010 12:23:17 -0700 (PDT)
Received: by qyk30 with SMTP id 30so258895qyk.10 for <nfsv4@ietf.org>; Thu, 30 Sep 2010 12:24:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=chd72V4tX5FXu/XlHBLrREwzzLOu5eFzXmIRoUjGjWs=; b=nzC4XWBB8KDwXzyhLKTc0Lqks0sZ/PG9tsP8PfgDtap61XL3NYN83hNkpSTRD36E8g lUEwbtTTLrgR3n2AVEZfNKk7AyJLkcerR1Rb0hVpq9KkGnFJHXoRmzJenl0CAqzJ33KQ oSZ3JzWt9zQleJqtJ+2rszUUeuh2zFA19Agpc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=YgrYlzyv5ABdDIKDTPcVLzM+5qtb9vYlVURAv5PdzfZUwTWUKdTzXHt4vh4OXZBMjI cRwWBWrfZKgZf6cNbDz69ySebO67MbrRoQ8Mb9Wx0/Nfl3L0i863w6SKJye6ckKvRdU6 drgvfnely9LDNyKb90jeQUvMO1dEztr2Qgm/I=
Received: by 10.229.187.209 with SMTP id cx17mr2995835qcb.268.1285874643798; Thu, 30 Sep 2010 12:24:03 -0700 (PDT)
Received: from [192.168.1.43] (pool-71-112-128-104.sttlwa.dsl-w.verizon.net [71.112.128.104]) by mx.google.com with ESMTPS id e6sm216789qcr.29.2010.09.30.12.24.01 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Sep 2010 12:24:02 -0700 (PDT)
Message-ID: <4CA4E3CC.2030900@gmail.com>
Date: Thu, 30 Sep 2010 12:23:56 -0700
From: Dean Hildebrand <seattleplus@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: "J. Bruce Fields" <bfields@fieldses.org>
References: <4CA3CE95.10407@gmail.com> <20100930175927.GB11836@fieldses.org> <4CA4D56A.7040905@gmail.com> <20100930183752.GC11836@fieldses.org> <20100930191627.GB15207@fieldses.org>
In-Reply-To: <20100930191627.GB15207@fieldses.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] New version of sparse draft (draft-hildebrand-nfsv4-read-sparse-01.txt)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nfsv4>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2010 19:23:19 -0000

On 9/30/2010 12:16 PM, J. Bruce Fields wrote:
> On Thu, Sep 30, 2010 at 02:37:52PM -0400, J. Bruce Fields wrote:
>> On Thu, Sep 30, 2010 at 11:22:34AM -0700, Dean Hildebrand wrote:
>>>
>>> On 9/30/2010 10:59 AM, J. Bruce Fields wrote:
>>>> On Wed, Sep 29, 2010 at 04:41:09PM -0700, Dean Hildebrand wrote:
>>>>>   Hello,
>>>>>
>>>>> I uploaded a new version of our internet draft "Simple and Efficient
>>>>> Read Support for Sparse Files".
>>>>>
>>>>> http://www.ietf.org/id/draft-hildebrand-nfsv4-read-sparse-01.txt
>>>>>
>>>>> Please have a look and give us any feedback.
>>>>>
>>>>> The main changes are:
>>>>> 1) Added section regarding pNFS (which basically states that there
>>>>> are no real changes to how pNFS works)
>>>>> 2) Added example sparse read message flow
>>>>> 3) Added statement to the effect that if a client sends a read
>>>>> request for a chunk that ends in zeroes, the server can return a
>>>>> short read (thanks to Benny)
>>>>> 4) I didn't change the return value.  There was a suggestion to use
>>>>> a flag instead of overloaded the length parameter, but I'm not sure
>>>>> what this gives us (although it might be more clear in the doc)
>>>> How will the client take advantage of the data_length field?
>>> I'm not 100% sure what you are asking, but all read requests into
>>> the region specified by data_offset and data_length cannot be
>>> assumed to be zero.  The data must come from either the client cache
>>> or server.  The example was designed to answer this type of
>>> question, does it help?
>> I think I understand what data_offset *means*.  What I don't understand
>> is how the client can use data_offset to improve performance.
> Knowing that there may be nonzero values in the range
> [data_offset,data_offset+data_length] isn't very useful--you're still
> going to have to perform reads to get the data in that range.
>
> The information that really *is* useful is the information that all data
> in the range [read offset,data_offset] is zero.
>
> So data_length doesn't give the client any new information it can use.
>
> Simpler, I think, would be to either drop data_length entirely, or to
> return a range describing the extent of the current *hole*, instead of
> the extent of the next *non-hole*.
>
> And just write the spec to say that the server return means that a read
> of the returned range would have returned all zeroes.

I think the original motivation was for the client to adapt its requests 
using this field, so it wouldn't try to read into a hole.  So instead of 
reading 64K, which might go past data_offset+data_length, it simply 
reads the appropriate amount of data up until data_offset+data_length.  
Now, the server can always return a short read, but that does put the 
onus on the server to do fine-grained checking of zero and non-zero data 
for every read request, which may be quite onerous.  So I still think it 
has a purpose and should be kept in the draft.

btw, I like your comment regarding allocated and unallocated data.  I'll 
use that as motivation and refer to zero and non-zero data in the 
protocol description.

Dean
> --b.