From unknown Mon Aug 18 14:25:35 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#55724 <55724@debbugs.gnu.org> To: bug#55724 <55724@debbugs.gnu.org> Subject: Status: cp --reflink=always failing when --reflink=auto reflinks successfully on OpenZFS Reply-To: bug#55724 <55724@debbugs.gnu.org> Date: Mon, 18 Aug 2025 21:25:35 +0000 retitle 55724 cp --reflink=3Dalways failing when --reflink=3Dauto reflinks = successfully on OpenZFS reassign 55724 coreutils submitter 55724 Rich severity 55724 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Mon May 30 06:57:27 2022 Received: (at submit) by debbugs.gnu.org; 30 May 2022 10:57:27 +0000 Received: from localhost ([127.0.0.1]:42892 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvd5S-0000Ts-4g for submit@debbugs.gnu.org; Mon, 30 May 2022 06:57:27 -0400 Received: from lists.gnu.org ([209.51.188.17]:37034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvbSe-0001ha-G0 for submit@debbugs.gnu.org; Mon, 30 May 2022 05:13:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:32922) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nvbSd-0002fP-LU for bug-coreutils@gnu.org; Mon, 30 May 2022 05:13:16 -0400 Received: from mail-vk1-xa31.google.com ([2607:f8b0:4864:20::a31]:36381) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nvbSb-0008HL-LV for bug-coreutils@gnu.org; Mon, 30 May 2022 05:13:15 -0400 Received: by mail-vk1-xa31.google.com with SMTP id u188so4666145vku.3 for ; Mon, 30 May 2022 02:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=qS/NWrl42HR1HorfH9QQqP+0u0jmBp3SHF+iTqn/k6g=; b=HOMPJdsoJuhG8Lc0YUtyseykJLD2Hy5azy+9Ys9+Xd4z4KG2/Zwp7UBjPIIp9AHMSf zof2pnslgdsNB0miFmzlgyVIAkco6gFtXlL2hqIlMiZRP4j8sEXhbVINC9sEY6szHfiS lCfUTU6sIgKkMG/kH/VkcGFPq2sWyyXb5unNt0gljtmlNrdW01KP6q3Ite3UEM8W9sLy IfmWSR+bdcRQd3qvitDd+4n0eGNpzTNM3ejlR8ZJjIV7usgQvqosCiwiaNAjJNUV+rrR pynl5IYMRg5/3W6zujb9OWa962jGOVqsmw4b/kYFQygX9B+ObX9TpCN2yT+WUnZXGowT Pqaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qS/NWrl42HR1HorfH9QQqP+0u0jmBp3SHF+iTqn/k6g=; b=LtaZN2hIjJuk89SNjtAY9N9bE/RHdwiKOOVBuR0J/osQ2tU+EqBD2KQrAJ/kU2tUb3 1BGe7earVoJ0ZlJNuRvh+/KKPdkCnCFx40H8zBfzdXHgmeqINw7W59vV8SmbmRkOY4hE tv50HHzrSskqhXOpcbfQlWBA9ZqZ/vFCqB+OCOlRnniUMrowxa0593uOMlG+gx2B6U3C KkCEvENjyqUOFSpnfGp/3i5gHkYMYTVvTzM8/ojwfWzdwFTas9SIuNO54fZ1nSXsfcex pUVa3DuAGJSLPiEQg3MOjXqX3qtc7eWJSdVTyKQ6iQToUbjcGVjh33b5wwwaqP/77u77 cqnA== X-Gm-Message-State: AOAM530917kB6Q7GiYS/6Bx6h8qEDbgHYWoM+6udJA9MGnXr0mLsywfG cGiKjUkxVS00u7p7RenmYg7Q1pTXph2yn2DpV1cb2RU1tiY= X-Google-Smtp-Source: ABdhPJxiuPhe65KhPZzgFW4K646esJNmmpKIwk2qrPTlgiva8E9hz+psvjDUhVqFKQNcLAgioHAJEFacpu2FfFhMSMs= X-Received: by 2002:a1f:9b53:0:b0:357:a3e8:e9af with SMTP id d80-20020a1f9b53000000b00357a3e8e9afmr13282182vke.7.1653901992205; Mon, 30 May 2022 02:13:12 -0700 (PDT) MIME-Version: 1.0 From: Rich Date: Mon, 30 May 2022 05:13:05 -0400 Message-ID: Subject: cp --reflink=always failing when --reflink=auto reflinks successfully on OpenZFS To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary="000000000000bd241405e03710fe" Received-SPF: pass client-ip=2607:f8b0:4864:20::a31; envelope-from=rincebrain@gmail.com; helo=mail-vk1-xa31.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Mon, 30 May 2022 06:57:24 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000bd241405e03710fe Content-Type: text/plain; charset="UTF-8" Hi! So, OpenZFS is adding reflink support Soon(tm), including across filesystems on a pool, which is nice. Unfortunately, Linux's VFS returns EXDEV for trying FICLONE or FICLONERANGE (but not copy_file_range) cross-filesystem before you ever ask the filesystem-specific code, so currently, the following strange behavior occurs: On coreutils 8.30 or 8.32, cp --reflink=always across filesystems will fail with EXDEV and --reflink=auto will not reflink (because they're not trying copy_file_range as a fallback). On coreutils git, as of b3331d59e, cp --reflink=always across filesystems will fail with EXDEV without ever getting out of Linux's VFS code, cp --reflink=auto will reflink silently (since it falls back to copy_file_range after getting EXDEV), cp --reflink=never will not reflink. (On the same filesystem, in all of the above versions, cp --reflink=always and =auto do the same thing and reflink correctly.) I'm not sure what the "correct" behavior here should be, but at least =auto working and =always failing seems like a surprising and incorrect outcome to me, though it's not readily obvious to me how the code "should" flow instead to avoid that - and since the failure cases happen before calling into OpenZFS, I don't see any way it could be handled better there. Happy to point people at the WIP code being used to demonstrate this if it would be helpful, but this seems like it's only OpenZFS specific in that nobody else has this functionality but would hit this case (because IIUC btrfs avoids clone_file failing with EXDEV by pretending they're not distinct filesystems, and there's not many other FSes where reflink across filesystems would make sense). Thanks for any insights, - Rich --000000000000bd241405e03710fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi!

So, OpenZFS is adding reflink support Soon(tm)= , including across filesystems on a pool, which is nice.

Unfortunately, Linux's VFS returns EXDEV for trying FICLONE or F= ICLONERANGE=C2=A0(but not copy_file_range)=C2=A0cross-filesystem before you= ever ask the filesystem-specific code, so currently, the following strange= behavior occurs:

On coreutils 8.30 or 8.32, cp --= reflink=3Dalways across filesystems will fail with EXDEV and --reflink=3Dau= to will not reflink (because they're not trying copy_file_range as a fa= llback).
On coreutils git, as of=C2=A0b3331d59e, cp --reflink=3Da= lways across filesystems will fail with EXDEV without ever getting out of L= inux's VFS code, cp --reflink=3Dauto will reflink silently (since it fa= lls back to copy_file_range after getting EXDEV), cp --reflink=3Dnever will= not reflink.

(On the same filesystem, in all of t= he above versions, cp --reflink=3Dalways and =3Dauto do the same thing and = reflink correctly.)

I'm not sure what the &quo= t;correct" behavior here should be, but at least =3Dauto working and = =3Dalways failing seems like a surprising and incorrect outcome to me, thou= gh it's not readily obvious to me how the code "should" flow = instead to avoid that - and since the failure cases happen before calling i= nto OpenZFS, I don't see any way it could be handled better there.

Happy to point people at the WIP code being used to de= monstrate this if it would be helpful, but this seems like it's only Op= enZFS specific in that nobody else has this functionality but would hit thi= s case (because IIUC btrfs avoids clone_file failing with EXDEV by pretendi= ng they're not distinct filesystems, and there's not many other FSe= s where reflink across filesystems would make sense).

<= div>Thanks for any insights,
- Rich
--000000000000bd241405e03710fe-- From debbugs-submit-bounces@debbugs.gnu.org Mon May 30 11:04:17 2022 Received: (at 55724) by debbugs.gnu.org; 30 May 2022 15:04:17 +0000 Received: from localhost ([127.0.0.1]:45746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvgwL-0003Lq-0V for submit@debbugs.gnu.org; Mon, 30 May 2022 11:04:17 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:37791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvgwJ-0003Ld-9c for 55724@debbugs.gnu.org; Mon, 30 May 2022 11:04:15 -0400 Received: by mail-wr1-f45.google.com with SMTP id t6so15047130wra.4 for <55724@debbugs.gnu.org>; Mon, 30 May 2022 08:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=uYPVs0sMiY5hkoZOyPUOW0VLXqncRM5suaj5yqLegCs=; b=I/TdhMPm+EqXtR3KwxtwS1rH7f4UntOiSJjNoZ1NJXkaKrJs49JdSngeqXwosQBYWa ECgR3kBLxOYfTZo9XRJqQGflwdg/rTjYbnPjZc/5ziCxfE4sKg3dGja0PNHWSLzeYYLM Abo5asE9HegxgqN2tHxaB5Fo0nGQA9WMf7QUMGVdWNIavq9SFJpqAO+2jEJwQnwbZBvG uNMLoT/mlyJOc132mQgMJANcFy6QQp6aXiNRUH/wDoAJ9LwmNoBkmQvUC9N4e7zFPdn/ senx8fMHZ9sz3DuHkZNdFIiHbatKgmdaPTBxkVVwkw91NswGHTsIF11us4zcwv6tKfeN kZkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :subject:content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=uYPVs0sMiY5hkoZOyPUOW0VLXqncRM5suaj5yqLegCs=; b=TLkr4LoDRdqk2PfV8j4UQFHr8RojoZ8eUgIObHXrVc6FtBICCtkZ3XFMSLG7rjBqNP 5EPzRXhsNdSC/gMSSZLH4dVm8+y+UPwCrDmwC/nv2brLCZQ7ImMH6yM5Mk7KYP8kVvjN 1HhfKXiekoOhAwUjBZz24U7H9RPQUHIRqzg422FX9Y+X9NfQg1gKgVeY7z4YLJN3zB6R wJ0XnyyvmyTcTyKLo7IFxhg7touNyWhzvpRRyTmurtPCNKkyyQdBMRIddSnZua9zs5nY YvfcBi/RA6KRemo1/ZzACdMVzjdWyOuWQQSGsoyjz4Ktypv2SAp0mSwJHeFYZmpUaooD WkTQ== X-Gm-Message-State: AOAM531xTZugQFtnfYLrKxhGS6y+g0R6o7Sookm9KzGd70LuXqZ3bgI7 tp4cJk7HhGG0fs3cRQCqwCA= X-Google-Smtp-Source: ABdhPJzrPDI86xldW18CpH+dSe3RBpdUEjxd9S1j06YdcG2L6vuCjpx2zCfZniz0BSchIVdzgYxKyQ== X-Received: by 2002:a5d:6da6:0:b0:20f:bc8a:9400 with SMTP id u6-20020a5d6da6000000b0020fbc8a9400mr40159631wrs.274.1653923049330; Mon, 30 May 2022 08:04:09 -0700 (PDT) Received: from [192.168.1.9] (95-44-90-175-dynamic.agg2.lod.rsl-rtd.eircom.net. [95.44.90.175]) by smtp.googlemail.com with ESMTPSA id o1-20020a5d47c1000000b0020fff0ea0a3sm9431212wrc.116.2022.05.30.08.04.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 May 2022 08:04:08 -0700 (PDT) Message-ID: <39b99989-5f40-8529-d78c-1936efb9a313@draigBrady.com> Date: Mon, 30 May 2022 16:04:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101 Thunderbird/98.0 Subject: Re: bug#55724: cp --reflink=always failing when --reflink=auto reflinks successfully on OpenZFS Content-Language: en-US To: Rich , 55724@debbugs.gnu.org References: From: =?UTF-8?Q?P=c3=a1draig_Brady?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 55724 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 30/05/2022 10:13, Rich wrote: > Hi! > > So, OpenZFS is adding reflink support Soon(tm), including across > filesystems on a pool, which is nice. > > Unfortunately, Linux's VFS returns EXDEV for trying FICLONE or > FICLONERANGE (but not copy_file_range) cross-filesystem before you ever ask > the filesystem-specific code, so currently, the following strange behavior > occurs: > > On coreutils 8.30 or 8.32, cp --reflink=always across filesystems will fail > with EXDEV and --reflink=auto will not reflink (because they're not trying > copy_file_range as a fallback). > On coreutils git, as of b3331d59e, cp --reflink=always across filesystems > will fail with EXDEV without ever getting out of Linux's VFS code, cp > --reflink=auto will reflink silently (since it falls back to > copy_file_range after getting EXDEV), cp --reflink=never will not reflink. > > (On the same filesystem, in all of the above versions, cp --reflink=always > and =auto do the same thing and reflink correctly.) > > I'm not sure what the "correct" behavior here should be, but at least =auto > working and =always failing seems like a surprising and incorrect outcome > to me, though it's not readily obvious to me how the code "should" flow > instead to avoid that - and since the failure cases happen before calling > into OpenZFS, I don't see any way it could be handled better there. > > Happy to point people at the WIP code being used to demonstrate this if it > would be helpful, but this seems like it's only OpenZFS specific in that > nobody else has this functionality but would hit this case (because IIUC > btrfs avoids clone_file failing with EXDEV by pretending they're not > distinct filesystems, and there's not many other FSes where reflink across > filesystems would make sense). > > Thanks for any insights, > - Rich Thanks for the clear info. Yes this is an awkward one, which I'm not sure cp can do anything about. `cp --reflink=always` => ensure we can reflink or otherwise fail. Really the kernel has to behave appropriately there and not do the blanket assumption with EXDEV. cp can't determine from copy_file_range() whether a reflink was performed or not, so wouldn't be appropriate to use with --reflink=always. cheers, Pádraig From debbugs-submit-bounces@debbugs.gnu.org Mon May 30 19:31:50 2022 Received: (at 55724) by debbugs.gnu.org; 30 May 2022 23:31:50 +0000 Received: from localhost ([127.0.0.1]:46247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvorV-0001Lj-UR for submit@debbugs.gnu.org; Mon, 30 May 2022 19:31:50 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:53132) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvorU-0001LN-Ab for 55724@debbugs.gnu.org; Mon, 30 May 2022 19:31:49 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 07F7A16005E; Mon, 30 May 2022 16:31:42 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id wrRhqKaFYEGY; Mon, 30 May 2022 16:31:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 587B9160158; Mon, 30 May 2022 16:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Pzn1CITaaBde; Mon, 30 May 2022 16:31:41 -0700 (PDT) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2C89116005E; Mon, 30 May 2022 16:31:41 -0700 (PDT) Message-ID: Date: Mon, 30 May 2022 16:31:40 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Content-Language: en-US To: =?UTF-8?Q?P=c3=a1draig_Brady?= References: <39b99989-5f40-8529-d78c-1936efb9a313@draigBrady.com> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: bug#55724: cp --reflink=always failing when --reflink=auto reflinks successfully on OpenZFS In-Reply-To: <39b99989-5f40-8529-d78c-1936efb9a313@draigBrady.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55724 Cc: 55724@debbugs.gnu.org, Rich X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 5/30/22 08:04, P=C3=A1draig Brady wrote: > Really the kernel has to behave appropriately there > and not do the blanket assumption with EXDEV. I agree. VFS should be willing to try a cross-filesystem FICLONE. Not=20 only does copy_file_range not guarantee cloning; it is less efficient=20 even when it does clone, due to the need to find the holes in the source=20 file. From debbugs-submit-bounces@debbugs.gnu.org Tue May 31 06:09:55 2022 Received: (at 55724) by debbugs.gnu.org; 31 May 2022 10:09:55 +0000 Received: from localhost ([127.0.0.1]:46683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvyoz-0008Kw-Gp for submit@debbugs.gnu.org; Tue, 31 May 2022 06:09:55 -0400 Received: from mail-vs1-f49.google.com ([209.85.217.49]:41878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nvwxC-00050w-S4 for 55724@debbugs.gnu.org; Tue, 31 May 2022 04:10:16 -0400 Received: by mail-vs1-f49.google.com with SMTP id m2so12848742vsr.8 for <55724@debbugs.gnu.org>; Tue, 31 May 2022 01:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5AH5pqgijVFWYSkdnARYkJJcyHSDopmwtJfXdX6yk8s=; b=AxzYFGqanx0uQdOj2NfSZy0Dyb13q3BubuAytx0eNmQAXdPyQ12KTEurqpONRADJhm mjwlNotpfss2MmZpsbz4moVGyilYLKzdOoJSdrS2iKLu9C6mqQIxe6+c0PMP5UhbKzvR qbPd1a9JKk5Eya3PoapjtMJeXQTBPA+RW+Vm5ZmzUjB7RrE1DjfsflrR9lYuOIPxR1fO DK9AWNM+PtX76ZcGCHJ15jWIVFoavHfUvTjhVrZIELaH8+//rv5+9AvQIa3NuQoOM8sX h5o9Pt+mgSYMcWF6kPEqXAReBZkFV8kJWRrFb7+LbO48XIS4qALRsLqdrmbh6qrLpkO5 vksg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5AH5pqgijVFWYSkdnARYkJJcyHSDopmwtJfXdX6yk8s=; b=rCB02Q/sbvk6o9EE/apyRZkSp0goXbxTo+OX2cKUFCkT2RESM4iVBXt1Qfl2kC5THL WU0dauyCCueqTAz6krPSY8GniMnWpDIOpq1njnO27t334xGeacGOttNZktU+SROkhdZ5 nm4vMd2sfe6ZHLaBZCwpS2F3tWXksTYiScbSbjC1iZH6YZsAYw1OuKtImWrMqyZ5tBww pXZiCScNdjxCAgbr9dsoJ9+Cr+h511MKtyJafDm7L6kWA0S6ubK3wjJFFBQWt5vJbGdD 84PvQ2iv7FQq43vpEAjRjM3DlDUkwttuLVi7pBcOWcQiQowfLmyow03LXoTwkEyt2Vxn ZabQ== X-Gm-Message-State: AOAM532zELaWOcVIJitdg2G0id8sJgStEVm/tkxhTZ9CAB8s9m5DApE3 8rNXMQp5GZTyO5lFTfEaI+NL7cqxaDcixdrSLVc= X-Google-Smtp-Source: ABdhPJwa81lN8JDW6BQCSafjepZDUe+OHx6EHkkM2IYLPuv7UldDHpZVKrb37P5VaJgoHpLdOSsyu39TX0H7MDxRJp8= X-Received: by 2002:a05:6102:11f6:b0:337:b698:c289 with SMTP id e22-20020a05610211f600b00337b698c289mr16639798vsg.31.1653984609303; Tue, 31 May 2022 01:10:09 -0700 (PDT) MIME-Version: 1.0 References: <39b99989-5f40-8529-d78c-1936efb9a313@draigBrady.com> In-Reply-To: From: Rich Date: Tue, 31 May 2022 04:10:01 -0400 Message-ID: Subject: Re: bug#55724: cp --reflink=always failing when --reflink=auto reflinks successfully on OpenZFS To: Paul Eggert Content-Type: multipart/alternative; boundary="00000000000019feb705e04a4d07" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55724 X-Mailman-Approved-At: Tue, 31 May 2022 06:09:52 -0400 Cc: 55724@debbugs.gnu.org, =?UTF-8?Q?P=C3=A1draig_Brady?= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000019feb705e04a4d07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 30, 2022 at 7:31 PM Paul Eggert wrote: > On 5/30/22 08:04, P=C3=A1draig Brady wrote: > > Really the kernel has to behave appropriately there > > and not do the blanket assumption with EXDEV. > > I agree. VFS should be willing to try a cross-filesystem FICLONE. Not > only does copy_file_range not guarantee cloning; it is less efficient > even when it does clone, due to the need to find the holes in the source > file. > I would also agree, it would be nice if those restrictions were removed. However, it has historically been the experience of both developers and users of OpenZFS that mentioning using it, finding bugs in other code because of it, or wanting things for it to LKML or any adjacent mailing list almost always results in "we don't care about out of tree, non-GPL code, tough shit" (which is why, for example, OpenZFS now implements its own FPU save/restore dance on x86). So, unfortunately, I suspect this situation will continue, and we will just document the behavior and explain that neither coreutils nor OpenZFS can do anything about it without violating correctness other ways. Thanks for your thoughts, - Rich --00000000000019feb705e04a4d07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, May 30, 2022 at 7:31 PM Paul Egge= rt <eggert@cs.ucla.edu> wro= te:
On 5/30/22 0= 8:04, P=C3=A1draig Brady wrote:
> Really the kernel has to behave appropriately there
> and not do the blanket assumption with EXDEV.

I agree. VFS should be willing to try a cross-filesystem FICLONE. Not
only does copy_file_range not guarantee cloning; it is less efficient
even when it does clone, due to the need to find the holes in the source file.

I would also agree, it would be n= ice if those restrictions=C2=A0were removed.

Howev= er, it has historically been the experience of both developers and users of= OpenZFS that mentioning using it, finding bugs in other code because of it= , or wanting things for it to LKML or any adjacent=C2=A0mailing list almost= always results in "we don't care about out of tree, non-GPL code,= tough shit" (which is why, for example, OpenZFS now implements its ow= n FPU save/restore dance on x86).

So, unfortunatel= y, I suspect this situation will continue, and we will just document the be= havior and explain that neither coreutils nor OpenZFS can do anything about= it without violating correctness other ways.
=C2=A0
Th= anks for your thoughts,
- Rich
--00000000000019feb705e04a4d07--