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

<david.noveck@emc.com> Fri, 01 October 2010 16:06 UTC

Return-Path: <david.noveck@emc.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 02BFA3A6E3E for <nfsv4@core3.amsl.com>; Fri, 1 Oct 2010 09:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.644
X-Spam-Level:
X-Spam-Status: No, score=-7.644 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_00=-2.599, GB_I_LETTER=-2, 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 5JH8D0iUpMvo for <nfsv4@core3.amsl.com>; Fri, 1 Oct 2010 09:06:51 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 564AA3A6CC0 for <nfsv4@ietf.org>; Fri, 1 Oct 2010 09:06:51 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o91G7XB9031925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Oct 2010 12:07:33 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 1 Oct 2010 12:07:30 -0400
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o91G7GO4003774; Fri, 1 Oct 2010 12:07:16 -0400
Received: from CORPUSMX50A.corp.emc.com ([128.221.62.39]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Oct 2010 12:07:15 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 01 Oct 2010 12:07:15 -0400
Message-ID: <BF3BB6D12298F54B89C8DCC1E4073D80027654B5@CORPUSMX50A.corp.emc.com>
In-Reply-To: <20101001153934.GG17310@fieldses.org>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] New version of sparse draft (draft-hildebrand-nfsv4-read-sparse-01.txt)
Thread-Index: ActhfxNlSmW5pp5uSQWdNW/bFJfz+wAAMVTg
References: <4CA3CE95.10407@gmail.com> <20101001143614.GB17310@fieldses.org><4CA5FCE6.6090406@panasas.com> <20101001153934.GG17310@fieldses.org>
From: david.noveck@emc.com
To: bfields@fieldses.org, bhalevy@panasas.com
X-OriginalArrivalTime: 01 Oct 2010 16:07:15.0956 (UTC) FILETIME=[B753DB40:01CB6182]
X-EMM-MHVC: 1
Cc: 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 16:06:53 -0000

> I think it would be amusing to have a version of READ that 
> implements the rsync protocol.  (Here's my checksum of the 
> data in the range; tell me I'm right, or give the real data 
> if not.) 

I agree it is amusing.

However, the people for whom it is amusing are a strange sort of people.
That is, they are like us.  It definitely will not work as stand-up,
even at an IETF meeting, even with a drummer behind you for sound
effects

I note that amusement is not on Mike's requirement list for v4.2 but
Spencer has told us that that is not a bar.  At this point, I kind of
feel that amusing ops might be good.  

With copy as well, we are definitely moving in the direction of avoiding
reads with special ops that process the data on the remote side.  The
general case is that you send some sort of program to process the data
on the remote side but that prospect is more depressing than amusing.

BTW, I agree that trying to hack READ is losing battle.  If you think
there is any prospect of other sorts of such function, rather than new
ops for each, I would have one new op and an enum to facilitate that
expansion.  Then you could use the new op to do plain READ, READZ, and
anything else that the group later finds amusing/useful

-----Original Message-----
From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf
Of J. Bruce Fields
Sent: Friday, October 01, 2010 11:40 AM
To: Benny Halevy
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] New version of sparse draft
(draft-hildebrand-nfsv4-read-sparse-01.txt)

On Fri, Oct 01, 2010 at 05:23:18PM +0200, Benny Halevy wrote:
> On 2010-10-01 16:36, 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
> > 
> > A couple other points:
> > 
> > 	- By returning an error in a situation that isn't really an
> > 	  error, we abort processing the compound when we don't really
> > 	  need to.  I suppose we could make a special exceptions for
> > 	  NFS4ERR_HOLE, but, yuch.
> > 	- The server can't return NFS4ERR_HOLE unless it knows the
> > 	  client is prepared to handle it.  One solution would be to
> > 	  make client support for NFS4ERR_HOLE mandatory in whichever
> > 	  minor version we add sparse-read support.  Whether that works
> > 	  well may depend on the eventual size of the minor version.
> > 	  It's easier if people can increment new features
> > 	  incrementally.
> 
> As I said in the meeting I'd be happier with a revised READ operation
> that officially support holes rather than hacking the existing op.

I'd be for that.

As long as the name of the new operation includes the letter "Z".

> While at that, I'd add an optional prefetch value to the args to
> help client-directed readahead.

I think it would be amusing to have a version of READ that implements
the rsync protocol.  (Here's my checksum of the data in the range; tell
me I'm right, or give the real data if not.)

(Maybe that one would need a "Y" in the name.)

--b.
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4