GNU bug report logs - #55724
cp --reflink=always failing when --reflink=auto reflinks successfully on OpenZFS

Previous Next

Full log

View this message in rfc822 format

From: Rich <rincebrain <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 55724 <at> debbugs.gnu.org, Pádraig Brady <P <at> draigbrady.com>
Subject: bug#55724: cp --reflink=always failing when --reflink=auto reflinks successfully on OpenZFS
Date: Tue, 31 May 2022 04:10:01 -0400

[Message part 1 (text/plain, inline)]

On Mon, May 30, 2022 at 7:31 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 5/30/22 08:04, Pádraig 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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.