[nfsv4] Fwd: New Version Notification for draft-lentini-nfsv4-server-side-copy-06

James Lentini <jlentini@netapp.com> Fri, 22 October 2010 01:52 UTC

Return-Path: <jlentini@netapp.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 49C093A6842 for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 18:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.798
X-Spam-Level:
X-Spam-Status: No, score=-7.798 tagged_above=-999 required=5 tests=[AWL=2.801, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 iwWnJQP9NaOS for <nfsv4@core3.amsl.com>; Thu, 21 Oct 2010 18:52:55 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 778BF3A6840 for <nfsv4@ietf.org>; Thu, 21 Oct 2010 18:52:55 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,221,1286175600"; d="scan'208";a="471245726"
Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 21 Oct 2010 18:54:32 -0700
Received: from jlentini-linux.hq.netapp.com (jlentini-linux.hq.netapp.com [10.97.16.21]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o9M1sVox010669 for <nfsv4@ietf.org>; Thu, 21 Oct 2010 18:54:32 -0700 (PDT)
Date: Thu, 21 Oct 2010 21:54:31 -0400
From: James Lentini <jlentini@netapp.com>
X-X-Sender: jlentini@jlentini-linux.nane.netapp.com
To: nfsv4@ietf.org
In-Reply-To: <20101022014724.BA1AC3A67FA@core3.amsl.com>
Message-ID: <alpine.LFD.2.00.1010212149520.4707@jlentini-linux.nane.netapp.com>
References: <20101022014724.BA1AC3A67FA@core3.amsl.com>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: [nfsv4] Fwd: New Version Notification for draft-lentini-nfsv4-server-side-copy-06
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, 22 Oct 2010 01:52:56 -0000

On Thu, 21 Oct 2010, IETF I-D Submission Tool wrote:

> 
> A new version of I-D, draft-lentini-nfsv4-server-side-copy-06.txt has been successfully submitted by James Lentini and posted to the IETF repository.
> 
> Filename:	 draft-lentini-nfsv4-server-side-copy
> Revision:	 06
> Title:		 NFS Server-side Copy
> Creation_date:	 2010-10-21
> WG ID:		 Independent Submission
> Number_of_pages: 37
> 
> Abstract:
> This document describes a set of NFS operations for offloading a file
> copy to a file server or between two file servers.
>                                                                                   
> 
> 
> The IETF Secretariat.

An updated version of the server-side copy proposal is now 
available. The changes from the previous version are:

 - Clarify copying metadata. The previous -05 draft said that all the
   REQUIRED and RECOMMENDED attributes of the source file are copied
   to the destination file if the metadata flag is set. However, many
   of these attributes shouldn't be blindly copied from the source
   file to the destination file.

   The new version clarifies which attributes MUST or SHOULD be copied 
   to the destination file.

   The new version also states that the metadata flag is only 
   applicable to whole file copies.

 - Removed COPY4_SPACE_RESERVED flag and cited
   draft-iyer-nfsv4-space-reservation-ops draft.

 - Noted that the client can use standard NFSv4 operations to guard
   against concurrent modifications to the source file.

 - Clarified that a successful copy must result in identical data 
   in the NFS client's view of the source and destination file, but 
   the on disk representation may be different due to backend
   encryption/compression/deduplication/etc.