Re: [nfsv4] New version of sparse draft(draft-hildebrand-nfsv4-read-sparse-01.txt)
<david.noveck@emc.com> Sun, 03 October 2010 16:08 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 5DFCC3A6D70 for <nfsv4@core3.amsl.com>; Sun, 3 Oct 2010 09:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.666
X-Spam-Level:
X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 yxxT-R9JbRot for <nfsv4@core3.amsl.com>; Sun, 3 Oct 2010 09:08:17 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 0D8B03A6D7F for <nfsv4@ietf.org>; Sun, 3 Oct 2010 09:08:16 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o93G98QI021058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Oct 2010 12:09:08 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Sun, 3 Oct 2010 12:09:02 -0400
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o93G85YA011876; Sun, 3 Oct 2010 12:08:05 -0400
Received: from CORPUSMX50A.corp.emc.com ([128.221.62.39]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Oct 2010 12:08:04 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6315.2904E823"
Date: Sun, 03 Oct 2010 12:08:03 -0400
Message-ID: <BF3BB6D12298F54B89C8DCC1E4073D80027655E9@CORPUSMX50A.corp.emc.com>
In-Reply-To: <4CA63E48.5070903@gmail.com>
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: ActhpAot6awLtNyeSzuuUgJJEQlv/ABbuNnw
References: <4CA3CE95.10407@gmail.com><E043D9D8EE3B5743B8B174A814FD584F0A64D38F@TK5EX14MBXC124.redmond.corp.microsoft.com> <4CA63E48.5070903@gmail.com>
From: david.noveck@emc.com
To: seattleplus@gmail.com, sshepler@microsoft.com
X-OriginalArrivalTime: 03 Oct 2010 16:08:04.0916 (UTC) FILETIME=[29560F40:01CB6315]
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: Sun, 03 Oct 2010 16:08:19 -0000
> Therefore, the only way for us to benefit from a new operation > is if every client in existence stops using READ and switches to > use the new operation. If one client stops using READ, and takes advantage of the new operation, there is a benefit. The more clients that do that, the more benefit, so the benefits are incremental. Also, switching to the new operation is not a benefit if you don't use the new data. > So with a new operation, I'm just not sure what the guidance to > implementors would be? Use the operation when it helps you. Also if it simplifies your implementation to only have a single read-style operation, use it everywhere if you use it in some places. Stop using READ? No. It is not at as if we have a big need to get to a future v4.x in which READ is mandatory-to-not-implement. Keeping READ around is not a big deal for servers. We wanted a simple addition to the protocol, not to deprecate READ :) So don't deprecate READ. Saying READ++ has come nice new shiny features that can help you is not exactly deprecating READ. Saying "You old-fashioned stick in the mud still using READ, get out of that v4.1 rut" would be deprecating READ. I don't think we don't want to do that. The only sense in which I would favor deprecating READ would be in saying that future new functionality should not be added to it, even if you somehow could fit it. ________________________________ From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf Of Dean Hildebrand Sent: Friday, October 01, 2010 4:02 PM To: Spencer Shepler Cc: nfsv4@ietf.org Subject: Re: [nfsv4] New version of sparse draft(draft-hildebrand-nfsv4-read-sparse-01.txt) 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. While a new operation is simple, it puts all the onus on clients to call the correct function. Therefore, the only way for us to benefit from a new operation is if every client in existence stops using READ and switches to use the new operation. If they do that, then what's the point of having the READ operation at all? So with a new operation, I'm just not sure what the guidance to implementors would be? Stop using READ? We wanted a simple addition to the protocol, not to deprecate READ :) >This new operation could allow for ascatter/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? Yes, Bruce pointed out that my text switches between zero and unallocated. I need to clean up this language. But in fact, they are one and the same idea. The READ operation doesn't control space allocation, that would be create or write. The READ operation just wants to know if it should return data or a flag. We want to propose the FADVISE like operation mentioned in Mike's draft at some point, this might be a good place for space allocation information. Dean 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
- Re: [nfsv4] New version of sparse draft (draft-hi… Dean Hildebrand
- [nfsv4] New version of sparse draft (draft-hildeb… Dean Hildebrand
- Re: [nfsv4] New version of sparse draft (draft-hi… Matt W. Benjamin
- Re: [nfsv4] New version of sparse draft (draft-hi… Thomas Haynes
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… Dean Hildebrand
- Re: [nfsv4] New version of sparse draft (draft-hi… Dean Hildebrand
- Re: [nfsv4] New version of sparse draft (draft-hi… Thomas Haynes
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… Benny Halevy
- [nfsv4] Fwd: Re: New version of sparse draft (dra… Benny Halevy
- Re: [nfsv4] New version of sparse draft (draft-hi… Benny Halevy
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… Dean Hildebrand
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… Marc Eshel
- Re: [nfsv4] New version of sparse draft (draft-hi… david.noveck
- [nfsv4] Fwd: Re: New version of sparse draft (dra… Benny Halevy
- Re: [nfsv4] New version of sparse draft (draft-hi… Benny Halevy
- Re: [nfsv4] New version of sparse draft (draft-hi… david.noveck
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… Spencer Shepler
- Re: [nfsv4] New version of sparse draft (draft-hi… Marc Eshel
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… Spencer Shepler
- Re: [nfsv4] New version of sparse draft (draft-hi… Marc Eshel
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… Dean Hildebrand
- Re: [nfsv4] New version of sparse draft (draft-hi… Spencer Shepler
- Re: [nfsv4] New version of sparse draft (draft-hi… Dean Hildebrand
- Re: [nfsv4] New version of sparse draft (draft-hi… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft (draft-hi… Dean Hildebrand
- Re: [nfsv4] New version of sparse draft (draft-hi… Benny Halevy
- Re: [nfsv4] New version of sparse draft (draft-hi… Dean Hildebrand
- Re: [nfsv4] New version of sparse draft(draft-hil… Erasani, Pranoop
- Re: [nfsv4] New version of sparse draft(draft-hil… Matt W. Benjamin
- Re: [nfsv4] New version of sparsedraft(draft-hild… Erasani, Pranoop
- Re: [nfsv4] New version of sparse draft(draft-hil… J. Bruce Fields
- Re: [nfsv4] New version of sparse draft(draft-hil… Erasani, Pranoop
- Re: [nfsv4] New version of sparse draft (draft-hi… James Lentini
- Re: [nfsv4] New version of sparse draft(draft-hil… david.noveck
- Re: [nfsv4] New version of sparse draft(draft-hil… J. Bruce Fields