From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= Subject: Re: [PATCH v1 0/8] VFS: In-kernel copy system call Date: Tue, 08 Sep 2015 21:03:09 +0100 Message-ID: <55EF3EFD.3080302@draigBrady.com> References: <1441397823-1203-1-git-send-email-Anna.Schumaker@Netapp.com> <55EEFCEE.5090000@draigBrady.com> <55EF279B.3020101@Netapp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Lutomirski , Anna Schumaker Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux btrfs Developers List , Linux FS Devel , Linux API , Zach Brown , Al Viro , Chris Mason , "Darrick J. Wong" , Michael Kerrisk-manpages , andros-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org, Christoph Hellwig , Coreutils List-Id: linux-api@vger.kernel.org On 08/09/15 20:10, Andy Lutomirski wrote: > On Tue, Sep 8, 2015 at 11:23 AM, Anna Schumaker > wrote: >> On 09/08/2015 11:21 AM, P=C3=A1draig Brady wrote: >>> I see copy_file_range() is a reflink() on BTRFS? >>> That's a bit surprising, as it avoids the copy completely. >>> cp(1) for example considered doing a BTRFS clone by default, >>> but didn't due to expectations that users actually wanted >>> the data duplicated on disk for resilience reasons, >>> and for performance reasons so that write latencies were >>> restricted to the copy operation, rather than being >>> introduced at usage time as the dest file is CoW'd. >>> >>> If reflink() is a possibility for copy_file_range() >>> then could it be done optionally with a flag? >> >> The idea is that filesystems get to choose how to handle copies in t= he default case. BTRFS could do a reflink, but NFS could do a server s= ide copy instead. I can change the default behavior to only do a data = copy (unless the reflink flag is specified) instead, if that is desirab= le. >> >> What does everybody think? >=20 > I think the best you could do is to have a hint asking politely for > the data to be deep-copied. After all, some filesystems reserve the > right to transparently deduplicate. >=20 > Also, on a true COW filesystem (e.g. btrfs sometimes), there may be n= o > advantage to deep copying unless you actually want two copies for > locality reasons. Agreed. The relink and server side copy are separate things. There's no advantage to not doing a server side copy, but as mentioned there may be advantages to doing deep copies on BTRFS (another reason not previous mentioned in this thread, would be to avoid ENOSPC errors at some time in the future). So having control over the deep copy seems useful. It's debatable whether ALLOW_REFLINK should be on/off by default for copy_file_range(). I'd be inclined to have such a setting off by d= efault, but cp(1) at least will work with whatever is chosen. thanks, P=C3=A1draig. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.vodafone.ie ([213.233.128.43]:33197 "EHLO mail1.vodafone.ie" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751862AbbIHUDN (ORCPT ); Tue, 8 Sep 2015 16:03:13 -0400 Message-ID: <55EF3EFD.3080302@draigBrady.com> Date: Tue, 08 Sep 2015 21:03:09 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= MIME-Version: 1.0 To: Andy Lutomirski , Anna Schumaker CC: linux-nfs@vger.kernel.org, Linux btrfs Developers List , Linux FS Devel , Linux API , Zach Brown , Al Viro , Chris Mason , "Darrick J. Wong" , Michael Kerrisk-manpages , andros@netapp.com, Christoph Hellwig , Coreutils Subject: Re: [PATCH v1 0/8] VFS: In-kernel copy system call References: <1441397823-1203-1-git-send-email-Anna.Schumaker@Netapp.com> <55EEFCEE.5090000@draigBrady.com> <55EF279B.3020101@Netapp.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 08/09/15 20:10, Andy Lutomirski wrote: > On Tue, Sep 8, 2015 at 11:23 AM, Anna Schumaker > wrote: >> On 09/08/2015 11:21 AM, Pádraig Brady wrote: >>> I see copy_file_range() is a reflink() on BTRFS? >>> That's a bit surprising, as it avoids the copy completely. >>> cp(1) for example considered doing a BTRFS clone by default, >>> but didn't due to expectations that users actually wanted >>> the data duplicated on disk for resilience reasons, >>> and for performance reasons so that write latencies were >>> restricted to the copy operation, rather than being >>> introduced at usage time as the dest file is CoW'd. >>> >>> If reflink() is a possibility for copy_file_range() >>> then could it be done optionally with a flag? >> >> The idea is that filesystems get to choose how to handle copies in the default case. BTRFS could do a reflink, but NFS could do a server side copy instead. I can change the default behavior to only do a data copy (unless the reflink flag is specified) instead, if that is desirable. >> >> What does everybody think? > > I think the best you could do is to have a hint asking politely for > the data to be deep-copied. After all, some filesystems reserve the > right to transparently deduplicate. > > Also, on a true COW filesystem (e.g. btrfs sometimes), there may be no > advantage to deep copying unless you actually want two copies for > locality reasons. Agreed. The relink and server side copy are separate things. There's no advantage to not doing a server side copy, but as mentioned there may be advantages to doing deep copies on BTRFS (another reason not previous mentioned in this thread, would be to avoid ENOSPC errors at some time in the future). So having control over the deep copy seems useful. It's debatable whether ALLOW_REFLINK should be on/off by default for copy_file_range(). I'd be inclined to have such a setting off by default, but cp(1) at least will work with whatever is chosen. thanks, Pádraig.