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

Marc Eshel <eshel@almaden.ibm.com> Fri, 01 October 2010 17:28 UTC

Return-Path: <eshel@almaden.ibm.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 99D613A6C2C for <nfsv4@core3.amsl.com>; Fri, 1 Oct 2010 10:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 O7tGm+OR3c-0 for <nfsv4@core3.amsl.com>; Fri, 1 Oct 2010 10:28:28 -0700 (PDT)
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id E83893A6C1C for <nfsv4@ietf.org>; Fri, 1 Oct 2010 10:28:27 -0700 (PDT)
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o91HKN0g025729 for <nfsv4@ietf.org>; Fri, 1 Oct 2010 11:20:23 -0600
Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o91HT91S205670 for <nfsv4@ietf.org>; Fri, 1 Oct 2010 11:29:09 -0600
Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o91HT9VS004029 for <nfsv4@ietf.org>; Fri, 1 Oct 2010 11:29:09 -0600
Received: from [127.0.0.1] ([9.1.58.30]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o91HT5bR003855; Fri, 1 Oct 2010 11:29:07 -0600
Message-ID: <4CA61A57.90205@almaden.ibm.com>
Date: Fri, 01 Oct 2010 10:28:55 -0700
From: Marc Eshel <eshel@almaden.ibm.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: Spencer Shepler <sshepler@microsoft.com>
References: <4CA3CE95.10407@gmail.com> <E043D9D8EE3B5743B8B174A814FD584F0A64D38F@TK5EX14MBXC124.redmond.corp.microsoft.com>
In-Reply-To: <E043D9D8EE3B5743B8B174A814FD584F0A64D38F@TK5EX14MBXC124.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------010606030208050905040609"
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: Fri, 01 Oct 2010 17:28:29 -0000

  I can claim that trying to read unallocated part of the file is and 
error :) but I see the point of complicating the error handling.  We can 
instead just add more information to the reply without giving the error 
return code.
I think this a simple solution that should be agreed on as alternative 
if we don't have a more general solution that will cover the requirement 
for this one.
This is a good example how we this group start with simple ideas and 
ending up with a conflicted and convoluted protocol that drags for years.
We proposed it, I believe we got consensus. We can fine tune it to make 
every one happy. If someone has a better idea let them write a draft and 
if the group agrees that it is a solution we can switch to the new 
proposed draft.
Marc.



On 10/1/2010 9:38 AM, Spencer Shepler wrote:
>
> Thanks for the update, Dean.
>
> I tend to agree with others that it is likely best to introduce a new 
> READ operation that
>
> incorporates the ideas presented in this draft.  This new operation 
> could allow for a
>
> scatter/gather-like mechanism.  Allowing the client to do a 1MB read 
> and obtain all
>
> of the data within that range while reducing the amount of data 
> transferred is
>
> attractive.
>
> More generally, your draft does combine the idea of space allocated at 
> the server
>
> for the file with the method of effective transfer of data when zeros 
> or unallocated
>
> or uninitialized ranges exist.  It is fine to combine the two ideas in 
> the draft but
>
> a little more explicit language would be helpful (I will make some 
> suggestions offline).
>
> It may be helpful to combine the these READ hole ideas with space 
> allocation
>
> controls provided to the client (allocate, release/trim, etc.).  
> Anyone else
>
> in the WG have an opinion here?
>
> Spencer
>
> *From:* nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] *On 
> Behalf Of *Dean Hildebrand
> *Sent:* Wednesday, September 29, 2010 4:41 PM
> *To:* nfsv4@ietf.org
> *Subject:* [nfsv4] New version of sparse draft 
> (draft-hildebrand-nfsv4-read-sparse-01.txt)
>
> 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)
>
> Dean
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4