IETF Logo Mail Archive

Re: [nfsv4] Server-side copy question

bfields@fieldses.org (J. Bruce Fields) Fri, 17 February 2017 19:52 UTC

Return-Path: <bfields@fieldses.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66FE129697 for <nfsv4@ietfa.amsl.com>; Fri, 17 Feb 2017 11:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyCkc3WblsLR for <nfsv4@ietfa.amsl.com>; Fri, 17 Feb 2017 11:52:21 -0800 (PST)
Received: from fieldses.org (fieldses.org [173.255.197.46]) by ietfa.amsl.com (Postfix) with ESMTP id DEBE5129663 for <nfsv4@ietf.org>; Fri, 17 Feb 2017 11:52:20 -0800 (PST)
Received: by fieldses.org (Postfix, from userid 2815) id BFB96A80; Fri, 17 Feb 2017 14:51:49 -0500 (EST)
Date: Fri, 17 Feb 2017 14:51:49 -0500
To: David Noveck <davenoveck@gmail.com>
Message-ID: <20170217195149.GH10894@fieldses.org>
References: <B65A07BE-E379-4507-A9B8-6927DF61A0A5@netapp.com> <CADaq8jdhK2NbJrAa0UHacvBS1w0ucoVpc1LJA3=mxH+_iBfMPQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CADaq8jdhK2NbJrAa0UHacvBS1w0ucoVpc1LJA3=mxH+_iBfMPQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
From: bfields@fieldses.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/FR02snbohe6ddjTdc0ZvDhXUsnk>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] Server-side copy question
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 17 Feb 2017 19:52:23 -0000

On Thu, Feb 16, 2017 at 08:00:36AM -0500, David Noveck wrote:
> I agree but think that the most expedient way of addressing this problem is
> in the Linux client,  It can check against the file size before issuing the
> COPY request  to prevent an erroneous INVAL error being returned.

That doesn't work, due to races with concurrent modifications to the
file.

The server itself would seem succeptible to such races: if it implements
the copy as a read-write loop then blocking concurrent truncates
probably isn't reasonable, so its only choice is a short copy.  (Too
late to return INVAL once you've written to the destination....).

I really think the spec's just wrong here.

--b.

v2.23.0 | Report a Bug | By Email