GNU logs - #48833, boring messages

Message sent to bug-coreutils@HIDDEN:

Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
Resent-From: Tom Yan <tom.ty89@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Fri, 04 Jun 2021 14:38:02 +0000
Resent-Message-ID: <handler.48833.B.162281747119074 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: linux-btrfs@HIDDEN
Cc: 48833 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
In-Reply-To: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
From: Tom Yan <tom.ty89@HIDDEN>
Date: Fri, 4 Jun 2021 22:37:35 +0800
Message-ID: <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2a00:1450:4864:20::12c;
 envelope-from=tom.ty89@HIDDEN; helo=mail-lf1-x12c.google.com
X-Spam_score_int: -17
X-Spam_score: -1.8
X-Spam_bar: -
X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.1 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

Also cc'ing bug-coreutils@HIDDEN

On Fri, 4 Jun 2021 at 22:33, Tom Yan <tom.ty89@HIDDEN> wrote:
>
> Hi all,
>
> I've just bumped into a problem that I am not sure what the expected
> behavior should be, but there seems to be something flawed.
>
> Say I have a file that was created with the No_COW attributed
> (inherited from the directory / subvolume / mount option). Then if I
> try to do a reflink copy, the copying will fail with "Invalid
> argument" if the copy has no one to inherit the No_COW attribute from.
>
> For example:
> [tom@archlinux mnt]$ sudo btrfs subvol list .
> ID 256 gen 11 top level 5 path a
> ID 257 gen 9 top level 5 path b
> [tom@archlinux mnt]$ lsattr
> ---------------------- ./a
> ---------------C------ ./b
> [tom@archlinux mnt]$ lsattr b/
> ---------------C------ b/test
> [tom@archlinux mnt]$ du -h b/test
> 512M    b/test
> [tom@archlinux mnt]$ lsattr a/
> [tom@archlinux mnt]$ cp --reflink=always b/test a/
> cp: failed to clone 'a/test' from 'b/test': Invalid argument
> [tom@archlinux mnt]$ lsattr a/
> ---------------------- a/test
> [tom@archlinux mnt]$ du a/test
> 0    a/test
> [tom@archlinux mnt]$ du --apparent-size a/test
> 0    a/test
> [tom@archlinux mnt]$ rm a/test
> [tom@archlinux mnt]$ sudo chattr +C a/
> [tom@archlinux mnt]$ cp --reflink=always b/test a/
> [tom@archlinux mnt]$ lsattr a/
> ---------------C------ a/test
> [tom@archlinux mnt]$ cmp b/test a/test
> [tom@archlinux mnt]$
>
> I'm not entirely sure if a reflink copy is supposed to work for a
> source file that was created with No_COW, but apparently it is. The
> problem is just that the reflink copy also needs to have the attribute
> set, yet it cannot inherit from the source automatically.
>
> I wonder if this is a kernel-side problem or something that coreutils
> missed? It also seems wrong that when it fails there will be an empty
> destination file created.
>
> Kernel version: Linux archlinux 5.12.8-arch1-1 #1 SMP PREEMPT Fri, 28
> May 2021 15:10:20 +0000 x86_64 GNU/Linux
> Coreutils version: 8.32
>
> Regards,
> Tom

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Tom Yan <tom.ty89@HIDDEN>
Subject: bug#48833: Acknowledgement (reflink copying does not check/set
 No_COW attribute and fail)
Message-ID: <handler.48833.B.162281747119074.ack <at> debbugs.gnu.org>
References: <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
X-Gnu-PR-Message: ack 48833
X-Gnu-PR-Package: coreutils
Reply-To: 48833 <at> debbugs.gnu.org
Date: Fri, 04 Jun 2021 14:38:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-coreutils@HIDDEN

If you wish to submit further information on this problem, please
send it to 48833 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
48833: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D48833
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-coreutils@HIDDEN:

Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
Resent-From: Zygo Blaxell <ce3g8jdj@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Fri, 04 Jun 2021 21:59:01 +0000
Resent-Message-ID: <handler.48833.B.16228439019886 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Tom Yan <tom.ty89@HIDDEN>
Cc: 48833 <at> debbugs.gnu.org, linux-btrfs@HIDDEN
Date: Fri, 4 Jun 2021 16:16:31 -0400
From: Zygo Blaxell <ce3g8jdj@HIDDEN>
Message-ID: <20210604201630.GH11733@HIDDEN>
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
 <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: pass client-ip=174.142.39.145;
 envelope-from=postmaster@HIDDEN; helo=james.kirk.hungrycats.org
X-Spam_score_int: -16
X-Spam_score: -1.7
X-Spam_bar: -
X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.1 (-)
X-Mailman-Approved-At: Fri, 04 Jun 2021 17:58:17 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

On Fri, Jun 04, 2021 at 10:37:35PM +0800, Tom Yan wrote:
> Also cc'ing bug-coreutils@HIDDEN
> 
> On Fri, 4 Jun 2021 at 22:33, Tom Yan <tom.ty89@HIDDEN> wrote:
> >
> > Hi all,
> >
> > I've just bumped into a problem that I am not sure what the expected
> > behavior should be, but there seems to be something flawed.
> >
> > Say I have a file that was created with the No_COW attributed
> > (inherited from the directory / subvolume / mount option). Then if I
> > try to do a reflink copy, the copying will fail with "Invalid
> > argument" if the copy has no one to inherit the No_COW attribute from.

Correct.  nodatacow implies nodatasum, and you cannot reflink an extent
from a nodatasum inode into a datasum inode.

The result of allowing this would be a file that has some extents
that have csums, and some that do not.  Making this work would make
reading from such a file worse (i.e. make it slower, or fail to detect
corruption in metadata).  It's possible to solve some of those problems
(or at least contain them in inodes that are known to have mixed csum
and non-csum data), but first someone would have to make the case that
this is worth the effort to support.

> > For example:
> > [tom@archlinux mnt]$ sudo btrfs subvol list .
> > ID 256 gen 11 top level 5 path a
> > ID 257 gen 9 top level 5 path b
> > [tom@archlinux mnt]$ lsattr
> > ---------------------- ./a
> > ---------------C------ ./b
> > [tom@archlinux mnt]$ lsattr b/
> > ---------------C------ b/test
> > [tom@archlinux mnt]$ du -h b/test
> > 512M    b/test
> > [tom@archlinux mnt]$ lsattr a/
> > [tom@archlinux mnt]$ cp --reflink=always b/test a/
> > cp: failed to clone 'a/test' from 'b/test': Invalid argument
> > [tom@archlinux mnt]$ lsattr a/
> > ---------------------- a/test
> > [tom@archlinux mnt]$ du a/test
> > 0    a/test
> > [tom@archlinux mnt]$ du --apparent-size a/test
> > 0    a/test
> > [tom@archlinux mnt]$ rm a/test
> > [tom@archlinux mnt]$ sudo chattr +C a/
> > [tom@archlinux mnt]$ cp --reflink=always b/test a/
> > [tom@archlinux mnt]$ lsattr a/
> > ---------------C------ a/test
> > [tom@archlinux mnt]$ cmp b/test a/test
> > [tom@archlinux mnt]$
> >
> > I'm not entirely sure if a reflink copy is supposed to work for a
> > source file that was created with No_COW, but apparently it is. 

Snapshots are also allowed for nodatacow files.  The extents that are
shared become implicitly datacow until they are not shared any more.

Snapshots are deferred reflink copies, so it would be difficult to
allow one and not the other.  Disallowing both seems overly restrictive
(e.g. with such a restriction, it would not be possible to use 'btrfs
send' or make a snapshot on a subvol that contains any nodatacow file).

btrfs did disallow both operations for swap files, so it could be possible
to disallow both reflinks and snapshots for nodatacow files, but AFAIK
nobody wants that (some people even want the swapfile restrictions to
go away someday).

> > The
> > problem is just that the reflink copy also needs to have the attribute
> > set, yet it cannot inherit from the source automatically.

reflink can only reflink copy from one nodatasum file to another nodatasum
file, or from one datasum file to another datasum file.

An empty inode can be changed from datacow to nodatacow (or vice versa)
using the fsattr ioctl, which simultaneously changes the file from
datasum to nodatasum if the filesystem was not mounted with the nodatasum
mount option.

There is a possible kernel enhancement here:  when an empty inode is the
dst of a reflink, automatically change the reflink dst inode's nodatasum
flag to match the reflink src inode's nodatasum flag.  If the dst inode
is not empty and the inode datasum flags do not match, then reject the
reflink with EINVAL as before.

It's not clear whether this should apply only to nodatasum or also to
nodatacow.  reflink doesn't need src and dst agreement on nodatacow,
so the dst inode could be a nodatasum+datacow file.  Unfortunately all
the userspace tools including coreutils can only see the nodatacow
inode bit, not the nodatasum bit, so the lack of csums on the dst file
would be invisible.  The kernel cannot know the user's intent from the
available information.

It's not clear that we want the kernel to be implicitly changing
inode attribute bits like this--especially bits that disable integrity
features like nodatasum.  There is precedent for changing fsattrs with
the no-compress inode flag, but that flag doesn't disable csums, and
this one would.

One could also make the opposite case:  it should always be an error to
do anything that would put data in a datasum file without csums, the
existing behavior is correct, and should not be changed.  The problem
with this argument is that users can't see the datasum inode bits,
so it's not clear that the EINVAL is a data protection mechanism.

> > I wonder if this is a kernel-side problem or something that coreutils
> > missed? It also seems wrong that when it fails there will be an empty
> > destination file created.

Normally coreutils will fall back to simple copy if --reflink=auto
is used.  --reflink=always is the user's explicit request for "reflink
or nothing, please."  The user correctly got nothing, as requested.

On other filesystems, reflink on a nodatacow file might make a simple
copy in the kernel--in which case you are no better off than if you had
used --reflink=auto.

coreutils could propagate the source inode nodatacow fsattribute to
the destination inode if it intends to use reflink to copy the data.
That would be the userspace equivalent of the kernel enhancement I
suggested above.  It would probably match user expectations better--no
hidden surprises for non-coreutils use cases, and all the affected inode
attribute bits are necessarily visible in userspace.

fsattr propagation could be quite complicated for coreutils to implement
correctly in general, as some fsattrs should not be propagated this way,
and other filesystems may have different restrictions.  Some fsattrs must
be set before the data is written (e.g. -c for compression), others must
be set after the data is written (e.g. -i for immutable), and some are
a matter of user intent (e.g. should a simple copy be compressed if the
source is not?  Depends on the intended use of the copy).

On other filesystems this userspace behavior might trigger the opposite
of the intended kernel behavior, causing reflink to always fall back to
simple copy because the dst inode's nodatacow attribute is set.

Ideally btrfs will not force coreutils to do one thing on btrfs and the
opposite thing on other filesystems, so it might be worthwhile to hack
around this in the kernel as proposed above.  There is precedent for
that--btrfs falls back to simple copy in reflinks of inline extents,
more or less for the sole purpose of making cp --reflink=always not fail
so randomly.

> > Kernel version: Linux archlinux 5.12.8-arch1-1 #1 SMP PREEMPT Fri, 28
> > May 2021 15:10:20 +0000 x86_64 GNU/Linux
> > Coreutils version: 8.32
> >
> > Regards,
> > Tom

Message sent to bug-coreutils@HIDDEN:

Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
Resent-From: Tom Yan <tom.ty89@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Sat, 05 Jun 2021 05:58:02 +0000
Resent-Message-ID: <handler.48833.B.162287262820808 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Zygo Blaxell <ce3g8jdj@HIDDEN>
Cc: 48833 <at> debbugs.gnu.org, linux-btrfs@HIDDEN
MIME-Version: 1.0
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
 <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
 <20210604201630.GH11733@HIDDEN>
In-Reply-To: <20210604201630.GH11733@HIDDEN>
From: Tom Yan <tom.ty89@HIDDEN>
Date: Sat, 5 Jun 2021 13:56:49 +0800
Message-ID: <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=2a00:1450:4864:20::131;
 envelope-from=tom.ty89@HIDDEN; helo=mail-lf1-x131.google.com
X-Spam_score_int: -17
X-Spam_score: -1.8
X-Spam_bar: -
X-Spam_report: (-1.8 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.1 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

As far as I'm concerned, inheriting an attribute from the source inode
isn't a "surprising" behavior. Rather it seems pretty "natural" to me.
And I don't think whether the attribute is "dangerous" changes that,
because if you consider it "dangerous", shouldn't you "watch out"
anyway when you try to make a clone of a source with such an
attribute?

If we see it from the way that, the kernel does not make the
destination inherit nodatasum just to make reflink succeed as much as
possible, but rather it just by design inherit nodatacow (for the
reason of being NOT surprising), then there's no concern in whether
they should "decoupled" when we implement the inheritance. (Like we
can't set only nodatasum with `chattr either. It's simply out of the
scope then.)

I don't know if we can do that based on whether the reflink mode is
always. Though we can fallback to "normal" copy when the source has
nodatasum (and/or nodatacow), personally I don't find it less
surprising than inheriting nodatacow all the time.

By the way, what will `chattr -C` do exactly if the file/inode had
nodatacow? Is the behavior different when it is / there is a reflink?

On Sat, 5 Jun 2021 at 04:16, Zygo Blaxell
<ce3g8jdj@HIDDEN> wrote:
>
> On Fri, Jun 04, 2021 at 10:37:35PM +0800, Tom Yan wrote:
> > Also cc'ing bug-coreutils@HIDDEN
> >
> > On Fri, 4 Jun 2021 at 22:33, Tom Yan <tom.ty89@HIDDEN> wrote:
> > >
> > > Hi all,
> > >
> > > I've just bumped into a problem that I am not sure what the expected
> > > behavior should be, but there seems to be something flawed.
> > >
> > > Say I have a file that was created with the No_COW attributed
> > > (inherited from the directory / subvolume / mount option). Then if I
> > > try to do a reflink copy, the copying will fail with "Invalid
> > > argument" if the copy has no one to inherit the No_COW attribute from.
>
> Correct.  nodatacow implies nodatasum, and you cannot reflink an extent
> from a nodatasum inode into a datasum inode.
>
> The result of allowing this would be a file that has some extents
> that have csums, and some that do not.  Making this work would make
> reading from such a file worse (i.e. make it slower, or fail to detect
> corruption in metadata).  It's possible to solve some of those problems
> (or at least contain them in inodes that are known to have mixed csum
> and non-csum data), but first someone would have to make the case that
> this is worth the effort to support.
>
> > > For example:
> > > [tom@archlinux mnt]$ sudo btrfs subvol list .
> > > ID 256 gen 11 top level 5 path a
> > > ID 257 gen 9 top level 5 path b
> > > [tom@archlinux mnt]$ lsattr
> > > ---------------------- ./a
> > > ---------------C------ ./b
> > > [tom@archlinux mnt]$ lsattr b/
> > > ---------------C------ b/test
> > > [tom@archlinux mnt]$ du -h b/test
> > > 512M    b/test
> > > [tom@archlinux mnt]$ lsattr a/
> > > [tom@archlinux mnt]$ cp --reflink=always b/test a/
> > > cp: failed to clone 'a/test' from 'b/test': Invalid argument
> > > [tom@archlinux mnt]$ lsattr a/
> > > ---------------------- a/test
> > > [tom@archlinux mnt]$ du a/test
> > > 0    a/test
> > > [tom@archlinux mnt]$ du --apparent-size a/test
> > > 0    a/test
> > > [tom@archlinux mnt]$ rm a/test
> > > [tom@archlinux mnt]$ sudo chattr +C a/
> > > [tom@archlinux mnt]$ cp --reflink=always b/test a/
> > > [tom@archlinux mnt]$ lsattr a/
> > > ---------------C------ a/test
> > > [tom@archlinux mnt]$ cmp b/test a/test
> > > [tom@archlinux mnt]$
> > >
> > > I'm not entirely sure if a reflink copy is supposed to work for a
> > > source file that was created with No_COW, but apparently it is.
>
> Snapshots are also allowed for nodatacow files.  The extents that are
> shared become implicitly datacow until they are not shared any more.
>
> Snapshots are deferred reflink copies, so it would be difficult to
> allow one and not the other.  Disallowing both seems overly restrictive
> (e.g. with such a restriction, it would not be possible to use 'btrfs
> send' or make a snapshot on a subvol that contains any nodatacow file).
>
> btrfs did disallow both operations for swap files, so it could be possible
> to disallow both reflinks and snapshots for nodatacow files, but AFAIK
> nobody wants that (some people even want the swapfile restrictions to
> go away someday).
>
> > > The
> > > problem is just that the reflink copy also needs to have the attribute
> > > set, yet it cannot inherit from the source automatically.
>
> reflink can only reflink copy from one nodatasum file to another nodatasum
> file, or from one datasum file to another datasum file.
>
> An empty inode can be changed from datacow to nodatacow (or vice versa)
> using the fsattr ioctl, which simultaneously changes the file from
> datasum to nodatasum if the filesystem was not mounted with the nodatasum
> mount option.
>
> There is a possible kernel enhancement here:  when an empty inode is the
> dst of a reflink, automatically change the reflink dst inode's nodatasum
> flag to match the reflink src inode's nodatasum flag.  If the dst inode
> is not empty and the inode datasum flags do not match, then reject the
> reflink with EINVAL as before.
>
> It's not clear whether this should apply only to nodatasum or also to
> nodatacow.  reflink doesn't need src and dst agreement on nodatacow,
> so the dst inode could be a nodatasum+datacow file.  Unfortunately all
> the userspace tools including coreutils can only see the nodatacow
> inode bit, not the nodatasum bit, so the lack of csums on the dst file
> would be invisible.  The kernel cannot know the user's intent from the
> available information.
>
> It's not clear that we want the kernel to be implicitly changing
> inode attribute bits like this--especially bits that disable integrity
> features like nodatasum.  There is precedent for changing fsattrs with
> the no-compress inode flag, but that flag doesn't disable csums, and
> this one would.
>
> One could also make the opposite case:  it should always be an error to
> do anything that would put data in a datasum file without csums, the
> existing behavior is correct, and should not be changed.  The problem
> with this argument is that users can't see the datasum inode bits,
> so it's not clear that the EINVAL is a data protection mechanism.
>
> > > I wonder if this is a kernel-side problem or something that coreutils
> > > missed? It also seems wrong that when it fails there will be an empty
> > > destination file created.
>
> Normally coreutils will fall back to simple copy if --reflink=auto
> is used.  --reflink=always is the user's explicit request for "reflink
> or nothing, please."  The user correctly got nothing, as requested.
>
> On other filesystems, reflink on a nodatacow file might make a simple
> copy in the kernel--in which case you are no better off than if you had
> used --reflink=auto.
>
> coreutils could propagate the source inode nodatacow fsattribute to
> the destination inode if it intends to use reflink to copy the data.
> That would be the userspace equivalent of the kernel enhancement I
> suggested above.  It would probably match user expectations better--no
> hidden surprises for non-coreutils use cases, and all the affected inode
> attribute bits are necessarily visible in userspace.
>
> fsattr propagation could be quite complicated for coreutils to implement
> correctly in general, as some fsattrs should not be propagated this way,
> and other filesystems may have different restrictions.  Some fsattrs must
> be set before the data is written (e.g. -c for compression), others must
> be set after the data is written (e.g. -i for immutable), and some are
> a matter of user intent (e.g. should a simple copy be compressed if the
> source is not?  Depends on the intended use of the copy).
>
> On other filesystems this userspace behavior might trigger the opposite
> of the intended kernel behavior, causing reflink to always fall back to
> simple copy because the dst inode's nodatacow attribute is set.
>
> Ideally btrfs will not force coreutils to do one thing on btrfs and the
> opposite thing on other filesystems, so it might be worthwhile to hack
> around this in the kernel as proposed above.  There is precedent for
> that--btrfs falls back to simple copy in reflinks of inline extents,
> more or less for the sole purpose of making cp --reflink=always not fail
> so randomly.
>
> > > Kernel version: Linux archlinux 5.12.8-arch1-1 #1 SMP PREEMPT Fri, 28
> > > May 2021 15:10:20 +0000 x86_64 GNU/Linux
> > > Coreutils version: 8.32
> > >
> > > Regards,
> > > Tom

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
Resent-From: Forza <forza@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Sat, 05 Jun 2021 16:21:02 +0000
Resent-Message-ID: <handler.48833.B.162291004332085 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 48833
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Tom Yan <tom.ty89@HIDDEN>, Zygo Blaxell <ce3g8jdj@HIDDEN>
Cc: 48833 <at> debbugs.gnu.org, linux-btrfs@HIDDEN
X-Debbugs-Original-Cc: bug-coreutils@HIDDEN, linux-btrfs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.162291004332085
          (code B ref -1); Sat, 05 Jun 2021 16:21:02 +0000
Received: (at submit) by debbugs.gnu.org; 5 Jun 2021 16:20:43 +0000
Received: from localhost ([127.0.0.1]:49948 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lpZ2O-0008LL-GJ
	for submit <at> debbugs.gnu.org; Sat, 05 Jun 2021 12:20:42 -0400
Received: from lists.gnu.org ([209.51.188.17]:40708)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <postmaster@HIDDEN>) id 1lpTej-0005wU-Bt
 for submit <at> debbugs.gnu.org; Sat, 05 Jun 2021 06:35:57 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:55736)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>)
 id 1lpTej-0002Cs-3T
 for bug-coreutils@HIDDEN; Sat, 05 Jun 2021 06:35:53 -0400
Received: from pio-pvt-msa3.bahnhof.se ([79.136.2.42]:35834)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>)
 id 1lpTef-00067R-PP
 for bug-coreutils@HIDDEN; Sat, 05 Jun 2021 06:35:52 -0400
Received: from localhost (localhost [127.0.0.1])
 by pio-pvt-msa3.bahnhof.se (Postfix) with ESMTP id AF3464590B;
 Sat,  5 Jun 2021 12:35:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at bahnhof.se
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=6.31
 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, URIBL_BLOCKED=0.001]
 autolearn=ham autolearn_force=no
Received: from pio-pvt-msa3.bahnhof.se ([127.0.0.1])
 by localhost (pio-pvt-msa3.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7_TPGxVMZjiY; Sat,  5 Jun 2021 12:35:45 +0200 (CEST)
Received: by pio-pvt-msa3.bahnhof.se (Postfix) with ESMTPA id C82713FBCD;
 Sat,  5 Jun 2021 12:35:44 +0200 (CEST)
Received: from [192.168.0.10] (port=59537)
 by tnonline.net with esmtpsa  (TLS1.3) tls TLS_AES_128_GCM_SHA256
 (Exim 4.94.2) (envelope-from <forza@HIDDEN>)
 id 1lpTec-000NAH-2k; Sat, 05 Jun 2021 12:35:44 +0200
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
 <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
 <20210604201630.GH11733@HIDDEN>
 <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
From: Forza <forza@HIDDEN>
Message-ID: <56d734d0-d0f6-4d64-7b6f-9ea8ad2858d4@HIDDEN>
Date: Sat, 5 Jun 2021 12:35:45 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=79.136.2.42; envelope-from=postmaster@HIDDEN;
 helo=pio-pvt-msa3.bahnhof.se
X-Spam_score_int: -24
X-Spam_score: -2.5
X-Spam_bar: --
X-Spam_report: (-2.5 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.59,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -2.0 (--)
X-Mailman-Approved-At: Sat, 05 Jun 2021 12:20:38 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.0 (---)



On 2021-06-05 07:56, Tom Yan wrote:
> As far as I'm concerned, inheriting an attribute from the source inode
> isn't a "surprising" behavior. Rather it seems pretty "natural" to me.
> And I don't think whether the attribute is "dangerous" changes that,
> because if you consider it "dangerous", shouldn't you "watch out"
> anyway when you try to make a clone of a source with such an
> attribute?

I'd agree here. 'cp -a' does mean preserve all attrributes. It is up the 
user to think about consequences copying nodatacow files.

> 
> If we see it from the way that, the kernel does not make the
> destination inherit nodatasum just to make reflink succeed as much as
> possible, but rather it just by design inherit nodatacow (for the
> reason of being NOT surprising), then there's no concern in whether
> they should "decoupled" when we implement the inheritance. (Like we
> can't set only nodatasum with `chattr either. It's simply out of the
> scope then.)
> 
> I don't know if we can do that based on whether the reflink mode is
> always. Though we can fallback to "normal" copy when the source has
> nodatasum (and/or nodatacow), personally I don't find it less
> surprising than inheriting nodatacow all the time.
> 
> By the way, what will `chattr -C` do exactly if the file/inode had
> nodatacow? Is the behavior different when it is / there is a reflink?

You cannot disable nodatacow on a file with existing contents.

There is already a thread from May 2020 on coreutils mailing list about 
the order of copying attributes to solve the issue of nodatacow etc.

Basically, 'cp -a' needs to set some file attributes before adding data 
to them.

https://lists.gnu.org/archive/html/coreutils/2020-05/msg00011.html

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
Resent-From: Zygo Blaxell <ce3g8jdj@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Sun, 06 Jun 2021 08:43:03 +0000
Resent-Message-ID: <handler.48833.B.16229689459421 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 48833
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Tom Yan <tom.ty89@HIDDEN>
Cc: 48833 <at> debbugs.gnu.org, linux-btrfs@HIDDEN
X-Debbugs-Original-Cc: bug-coreutils@HIDDEN, linux-btrfs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.16229689459421
          (code B ref -1); Sun, 06 Jun 2021 08:43:03 +0000
Received: (at submit) by debbugs.gnu.org; 6 Jun 2021 08:42:25 +0000
Received: from localhost ([127.0.0.1]:50589 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lpoMS-0002Rm-02
	for submit <at> debbugs.gnu.org; Sun, 06 Jun 2021 04:42:24 -0400
Received: from lists.gnu.org ([209.51.188.17]:44340)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <postmaster@HIDDEN>) id 1lplYc-0006Qd-VD
 for submit <at> debbugs.gnu.org; Sun, 06 Jun 2021 01:42:50 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:40176)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>)
 id 1lplYc-00069P-MM
 for bug-coreutils@HIDDEN; Sun, 06 Jun 2021 01:42:46 -0400
Received: from james.kirk.hungrycats.org ([174.142.39.145]:40934)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <postmaster@HIDDEN>) id 1lplYa-00031H-7Q
 for bug-coreutils@HIDDEN; Sun, 06 Jun 2021 01:42:46 -0400
Received: by james.kirk.hungrycats.org (Postfix, from userid 1002)
 id CC7DAA8F1A9; Sun,  6 Jun 2021 01:42:42 -0400 (EDT)
Date: Sun, 6 Jun 2021 01:42:42 -0400
From: Zygo Blaxell <ce3g8jdj@HIDDEN>
Message-ID: <20210606054242.GI11733@HIDDEN>
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
 <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
 <20210604201630.GH11733@HIDDEN>
 <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: pass client-ip=174.142.39.145;
 envelope-from=postmaster@HIDDEN; helo=james.kirk.hungrycats.org
X-Spam_score_int: -16
X-Spam_score: -1.7
X-Spam_bar: -
X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001 autolearn=no autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.1 (-)
X-Mailman-Approved-At: Sun, 06 Jun 2021 04:42:21 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

On Sat, Jun 05, 2021 at 01:56:49PM +0800, Tom Yan wrote:
> As far as I'm concerned, inheriting an attribute from the source inode
> isn't a "surprising" behavior. Rather it seems pretty "natural" to me.
> And I don't think whether the attribute is "dangerous" changes that,
> because if you consider it "dangerous", shouldn't you "watch out"
> anyway when you try to make a clone of a source with such an
> attribute?

It's important not to conflate the two contexts.  For cp -a, copying
attributes from the src inode might be obvious.  For any other application
(including cp with different arguments), it might be the worst possible
thing to do, especially if we've been doing the opposite for over
a decade.

People run btrfs on crappy SSD and MMC devices, where filesystem csums
are the only way to know the disk is failing (SMART is nonexistent,
and the firmware doesn't bother with any form of working ECC or CRC, so
the first indication of any drive failure is when it starts corrupting
data).  Disabling the datasum bit on any inode is eventually equivalent
to injecting a stream of random undetected corruption into the file when
the drive inevitably fails.  For users with such drives, a mount option
or filesystem feature flag to disable chattr +C globally would make sense,
as they never want any file to be nodatasum for any reason.

If cp -a implements the inode attribute propagation (or inheritance), then
only users of cp -a are impacted.  They are more likely to be aware that
they may be creating new files with reduced-integrity storage attributes.

> If we see it from the way that, the kernel does not make the
> destination inherit nodatasum just to make reflink succeed as much as
> possible, but rather it just by design inherit nodatacow (for the
> reason of being NOT surprising), then there's no concern in whether
> they should "decoupled" when we implement the inheritance. (Like we
> can't set only nodatasum with `chattr either. It's simply out of the
> scope then.)

Thw window for design of these features mostly closed in 2008.  If we
limit the scope as you suggest, we stuck with a lot of the current
behavior now because it is existing kernel API.

If we also fixed some of the other design issues, like the invisible
datasum attribute, we could make the case that at least these automatic
implied inode changes would be _visible to users_.  At the moment,
it requires special tools to inspect the filesystem to see that a file
has its nodatasum bit set, and we probably don't want to start silently
flipping any more inode bits users can't even see.  We already did that
with prealloc and no-compression attributes, and users find it difficult
to understand the resulting changes in btrfs behavior.  There are some
proposals in the works to make all the inode flags visible as xattr
properties, and if those are done then we can say "well at least you
can see that we now change the datasum attribute sometimes."  But it's
a very weak argument.

The kernel has no way to know it's running 'cp -a' or that the intent
is to copy an existing object.  A user could be constructing a new
object using a combination of writes and reflinks from other files
(e.g. a disk image compiler) and intend for the result to have csums
even if the reflinked source files did not.

The kernel only knows that it has been told to create a file with XZ
attributes, and later the user requests cloning data from a file with
XYZ attributes.  If the user didn't intend for the dst file to have
XYZ attributes (and why would she, when she created the file with XZ
attributes?), then it could be a serious regression if the file suddenly
ends up with unintended Y attributes on new kernels.  Without easy
userspace visibility of the nodatasum attribute, it would be difficult
to even _detect_ this change until after silent data corruption gets
bad enough to be noticed.

Contrast with the coreutils package, which has changed its behavior
several times since reflink was first introduced in 2009 to adapt to
changing user expectations.  Nobody expects coreutils to behave quite
the same way from one year to the next, so there is room for innovation
there--and users who don't want the innovations can fork coreutils or
use some other tools.  One such innovation could be to simply detect
this case and make the appropriate inode changes before copying.

On the other hand, maybe nobody has any existing software deployed that
depends on the old kernel behavior, so we can change it after all.  In the
dangerous case (cheap SSD), a sysadmin wouldn't have any nodatacow files
anywhere on the filesystem, so they wouldn't be making reflink copies
of them because none exist.  They could be making a copy of a nodatacow
file from another filesystem, but in that case they would be using normal
copy, since reflink doesn't work across filesystems.  Maybe we can find
all the users who are running reflinking disk image compilers and they
can update their code to work around the proposed new kernel behavior.

> I don't know if we can do that based on whether the reflink mode is
> always. Though we can fallback to "normal" copy when the source has
> nodatasum (and/or nodatacow), personally I don't find it less
> surprising than inheriting nodatacow all the time.

Note that the kernel never sees the reflink argument from cp.  It is
entirely implemented inside the 'cp' command.  In --reflink=auto mode,
cp will first try clone_range, and if the kernel rejects that with an
EINVAL error, then cp will try again with traditional read/write code.
This is after cp has already created the dst file.  The kernel does
not provide a "create a new file with the attributes of an old file"
call--cp has to create the file with open(), and then do a series of
chmod, chown, and setfattr calls in the right order to replicate the
attributes of the old file.

The kernel doesn't guarantee that reflinks are possible in all cases, and
generally does not provide any fallback.  There are multiple possible
responses to a reflink failure and the kernel cannot implement all
of them.  It is up to userspace (i.e. the cp command) to decide what a
correct fallback behavior should be, and then implement it.

> By the way, what will `chattr -C` do exactly if the file/inode had
> nodatacow? Is the behavior different when it is / there is a reflink?

If the file is empty, you can chattr +C or -C.  If the file is not
empty, chattr fails with an error.

All the data extents in a file have to have the same csum status (csum
present or csum absent) as the inode.  It is not allowed to change the
C attribute when data extents exist because the C attribute indirectly
affects whether the extents have data csums or not, and if the inode was
changed it would disagree with existing data extents.  If no data extents
exist (i.e. zero-length file), then the inode attribute can be changed,
because there is nothing present that could disagree with the inode.

It doesn't matter whether reflinks were previously made or not.  In btrfs
there is no difference between a reflink and any other write, in the
same way that there is no difference between a directory entry created
by hardlink versus any other file creation.  Normal writes create a
new data extent, then reflink it to exactly the spot in file where the
data was written.  clone_range creates a reflink to some data extent(s)
that already exist.  Like hardlinks, when a reflink copy is made, it is
not always possible to tell which was the original and which was the copy.

> On Sat, 5 Jun 2021 at 04:16, Zygo Blaxell
> <ce3g8jdj@HIDDEN> wrote:
> >
> > On Fri, Jun 04, 2021 at 10:37:35PM +0800, Tom Yan wrote:
> > > Also cc'ing bug-coreutils@HIDDEN
> > >
> > > On Fri, 4 Jun 2021 at 22:33, Tom Yan <tom.ty89@HIDDEN> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I've just bumped into a problem that I am not sure what the expected
> > > > behavior should be, but there seems to be something flawed.
> > > >
> > > > Say I have a file that was created with the No_COW attributed
> > > > (inherited from the directory / subvolume / mount option). Then if I
> > > > try to do a reflink copy, the copying will fail with "Invalid
> > > > argument" if the copy has no one to inherit the No_COW attribute from.
> >
> > Correct.  nodatacow implies nodatasum, and you cannot reflink an extent
> > from a nodatasum inode into a datasum inode.
> >
> > The result of allowing this would be a file that has some extents
> > that have csums, and some that do not.  Making this work would make
> > reading from such a file worse (i.e. make it slower, or fail to detect
> > corruption in metadata).  It's possible to solve some of those problems
> > (or at least contain them in inodes that are known to have mixed csum
> > and non-csum data), but first someone would have to make the case that
> > this is worth the effort to support.
> >
> > > > For example:
> > > > [tom@archlinux mnt]$ sudo btrfs subvol list .
> > > > ID 256 gen 11 top level 5 path a
> > > > ID 257 gen 9 top level 5 path b
> > > > [tom@archlinux mnt]$ lsattr
> > > > ---------------------- ./a
> > > > ---------------C------ ./b
> > > > [tom@archlinux mnt]$ lsattr b/
> > > > ---------------C------ b/test
> > > > [tom@archlinux mnt]$ du -h b/test
> > > > 512M    b/test
> > > > [tom@archlinux mnt]$ lsattr a/
> > > > [tom@archlinux mnt]$ cp --reflink=always b/test a/
> > > > cp: failed to clone 'a/test' from 'b/test': Invalid argument
> > > > [tom@archlinux mnt]$ lsattr a/
> > > > ---------------------- a/test
> > > > [tom@archlinux mnt]$ du a/test
> > > > 0    a/test
> > > > [tom@archlinux mnt]$ du --apparent-size a/test
> > > > 0    a/test
> > > > [tom@archlinux mnt]$ rm a/test
> > > > [tom@archlinux mnt]$ sudo chattr +C a/
> > > > [tom@archlinux mnt]$ cp --reflink=always b/test a/
> > > > [tom@archlinux mnt]$ lsattr a/
> > > > ---------------C------ a/test
> > > > [tom@archlinux mnt]$ cmp b/test a/test
> > > > [tom@archlinux mnt]$
> > > >
> > > > I'm not entirely sure if a reflink copy is supposed to work for a
> > > > source file that was created with No_COW, but apparently it is.
> >
> > Snapshots are also allowed for nodatacow files.  The extents that are
> > shared become implicitly datacow until they are not shared any more.
> >
> > Snapshots are deferred reflink copies, so it would be difficult to
> > allow one and not the other.  Disallowing both seems overly restrictive
> > (e.g. with such a restriction, it would not be possible to use 'btrfs
> > send' or make a snapshot on a subvol that contains any nodatacow file).
> >
> > btrfs did disallow both operations for swap files, so it could be possible
> > to disallow both reflinks and snapshots for nodatacow files, but AFAIK
> > nobody wants that (some people even want the swapfile restrictions to
> > go away someday).
> >
> > > > The
> > > > problem is just that the reflink copy also needs to have the attribute
> > > > set, yet it cannot inherit from the source automatically.
> >
> > reflink can only reflink copy from one nodatasum file to another nodatasum
> > file, or from one datasum file to another datasum file.
> >
> > An empty inode can be changed from datacow to nodatacow (or vice versa)
> > using the fsattr ioctl, which simultaneously changes the file from
> > datasum to nodatasum if the filesystem was not mounted with the nodatasum
> > mount option.
> >
> > There is a possible kernel enhancement here:  when an empty inode is the
> > dst of a reflink, automatically change the reflink dst inode's nodatasum
> > flag to match the reflink src inode's nodatasum flag.  If the dst inode
> > is not empty and the inode datasum flags do not match, then reject the
> > reflink with EINVAL as before.
> >
> > It's not clear whether this should apply only to nodatasum or also to
> > nodatacow.  reflink doesn't need src and dst agreement on nodatacow,
> > so the dst inode could be a nodatasum+datacow file.  Unfortunately all
> > the userspace tools including coreutils can only see the nodatacow
> > inode bit, not the nodatasum bit, so the lack of csums on the dst file
> > would be invisible.  The kernel cannot know the user's intent from the
> > available information.
> >
> > It's not clear that we want the kernel to be implicitly changing
> > inode attribute bits like this--especially bits that disable integrity
> > features like nodatasum.  There is precedent for changing fsattrs with
> > the no-compress inode flag, but that flag doesn't disable csums, and
> > this one would.
> >
> > One could also make the opposite case:  it should always be an error to
> > do anything that would put data in a datasum file without csums, the
> > existing behavior is correct, and should not be changed.  The problem
> > with this argument is that users can't see the datasum inode bits,
> > so it's not clear that the EINVAL is a data protection mechanism.
> >
> > > > I wonder if this is a kernel-side problem or something that coreutils
> > > > missed? It also seems wrong that when it fails there will be an empty
> > > > destination file created.
> >
> > Normally coreutils will fall back to simple copy if --reflink=auto
> > is used.  --reflink=always is the user's explicit request for "reflink
> > or nothing, please."  The user correctly got nothing, as requested.
> >
> > On other filesystems, reflink on a nodatacow file might make a simple
> > copy in the kernel--in which case you are no better off than if you had
> > used --reflink=auto.
> >
> > coreutils could propagate the source inode nodatacow fsattribute to
> > the destination inode if it intends to use reflink to copy the data.
> > That would be the userspace equivalent of the kernel enhancement I
> > suggested above.  It would probably match user expectations better--no
> > hidden surprises for non-coreutils use cases, and all the affected inode
> > attribute bits are necessarily visible in userspace.
> >
> > fsattr propagation could be quite complicated for coreutils to implement
> > correctly in general, as some fsattrs should not be propagated this way,
> > and other filesystems may have different restrictions.  Some fsattrs must
> > be set before the data is written (e.g. -c for compression), others must
> > be set after the data is written (e.g. -i for immutable), and some are
> > a matter of user intent (e.g. should a simple copy be compressed if the
> > source is not?  Depends on the intended use of the copy).
> >
> > On other filesystems this userspace behavior might trigger the opposite
> > of the intended kernel behavior, causing reflink to always fall back to
> > simple copy because the dst inode's nodatacow attribute is set.
> >
> > Ideally btrfs will not force coreutils to do one thing on btrfs and the
> > opposite thing on other filesystems, so it might be worthwhile to hack
> > around this in the kernel as proposed above.  There is precedent for
> > that--btrfs falls back to simple copy in reflinks of inline extents,
> > more or less for the sole purpose of making cp --reflink=always not fail
> > so randomly.
> >
> > > > Kernel version: Linux archlinux 5.12.8-arch1-1 #1 SMP PREEMPT Fri, 28
> > > > May 2021 15:10:20 +0000 x86_64 GNU/Linux
> > > > Coreutils version: 8.32
> > > >
> > > > Regards,
> > > > Tom

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
Resent-From: Leslie S Satenstein <lsatenstein@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 07 Jun 2021 02:02:01 +0000
Resent-Message-ID: <handler.48833.B48833.16230312711642 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 48833
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Tom Yan <tom.ty89@HIDDEN>,  Zygo Blaxell <ce3g8jdj@HIDDEN>
Cc: "48833 <at> debbugs.gnu.org" <48833 <at> debbugs.gnu.org>, "linux-btrfs@HIDDEN" <linux-btrfs@HIDDEN>
Reply-To: Leslie S Satenstein <lsatenstein@HIDDEN>
Received: via spool by 48833-submit <at> debbugs.gnu.org id=B48833.16230312711642
          (code B ref 48833); Mon, 07 Jun 2021 02:02:01 +0000
Received: (at 48833) by debbugs.gnu.org; 7 Jun 2021 02:01:11 +0000
Received: from localhost ([127.0.0.1]:54213 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lq4Zf-0000QL-Os
	for submit <at> debbugs.gnu.org; Sun, 06 Jun 2021 22:01:11 -0400
Received: from sonic304-22.consmr.mail.ne1.yahoo.com ([66.163.191.148]:36783)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <lsatenstein@HIDDEN>) id 1lq4ZZ-0000Pf-HZ
 for 48833 <at> debbugs.gnu.org; Sun, 06 Jun 2021 22:01:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1623031255; bh=wgOfJuvF88WLGFigTscT7GQtd70+YFzpKdIsec+RsSk=;
 h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To;
 b=nX17cY3UG51A58e8oTPQtgHqgJUZdmXuNrAXLbMzgHgSVUd+gjBllknnHzfaDdYOQ3XrRxR2OM+ewKXXxjeGeP2OwIKdUFqq8iCCOZMQeQgXm6ePuOZNSuETZyy19Rgnd5tTglAMXU7BAJ5acEqSDxNPdG3iDx3vuX1agPnT6+/NrzWfXbAsunIekci+h3pK1tXTFAqZAApQIcQgSrwTHF/wiCR/VnosReissWJpl02a++S/WMUOZlZnw9jeRwxRwMVMT7ST1Csf1bMD+0QnDVI50hbtD4i+VF38LGDyqbmrSDe0FCN9O3Pyi2KGJtvFG8J1XZDdpisAJr4xA06g1g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1623031255; bh=3KB8fP6LQSfmy5NQ62whqY+8hCYHKigm5Z7JWAfFkfX=;
 h=X-Sonic-MF:Date:From:To:Subject:From:Subject;
 b=jMeURQlBdmC/OprJbPDtep4NR0lbEwpisXtXSsKs83X0DUv5phNe1CDfUb6l8BGtu1FQ1/+GQcllZAIOCVdrroDiDB1TFkDV0ZPsjn0qLksURStYp93gktn+dL9M1sy0GCXZUgXo7700OWv+ZkIpkkwaCfWRKt8qNVQzuhI6Kaz3jO3i1GhcveCQRO9EgriPmtY5H5Y1Ppcxt/T65WOtJMIpk2MwQCuabkR2HRNoWmCiAH9DGczcfaUIpfBIHaA5cTKaikqNCZ0KIs4Zc36BfIX9EQd5CMt/crsOHXohFhCZaQGVHvEQ0OfqWtyFZAsYyLtplwcyXtnST2dpotjMTg==
X-YMail-OSG: 8YKMmDEVM1mKlY.Akhx71FGvUia1FruE8OADVcUUWqTO7WiDUAvw0BFyVnyYqJ5
 eSDt7em3mIJkRboE99jFSpoex1GgxqrCh8MG87U9kXozC1qPkzxE0YRg8kuU6DM33u2eKR6Uh5B2
 awAOaDZxzGd.HaCJJolP6yQlYfIRuEDZbfCxRnUfA78Ci0ajIWcqmwUjlEwuTh4pvYCM_oU75EzK
 S5o4O3Gxk4IDh7c4oMrZtLCGeCui_.L9ErSUTZ3NqykOhXqjqBFWL9QI8E8doa2n047izGZXPXU2
 g91MFi_f4DS5RPBgavvdRDYbjGcORW0jvumzqmFONoZdY04IWtQqYWaNMvJHwYOc.fixC48QhxWf
 5Jupyvwg4OzcSpOvk8PYCJTcv4QFXfyNLXbOhuxmRQPMezszdcVOsJi3NhRtCx0DXQPIxX0AJ_Un
 A3DfcFd.D1omitKcS_qIbgfz06Kos.V4V03Yj9kjLzEwmw_Ihc8e46m.8_hK8MHipVJzTL_Vqf93
 3Ueikf6ulV3n73CinuDPNVeHQ6I_7gCi0DjtpNmnXT82JvGwT33D6O94Brr16jb6nM6hZyNLKB5I
 BoHR_DLMtHV7DFcSx0ZHgurcB3ZEWBIhCGJgHIKgI_3qC9MOK10zdRi5qxMuUCTBHhagelZ6m9Xp
 UzOEu0_oiev9FzsjCnAYCzxDSZDSVlU_LCfayTm82zeqHQ0On5qVfeBh3xpFsliAXr4JDr2FarYn
 TAboUyiP80Ci0UaBsjIio6IxOfdP8aEZ3eIzNXKalbMMTRUbe6jatHgWHGjl1_80XGdcEjgKTyDi
 O1mh4WPpn079OuhqKTwGXeodXbrtQrw6t2KNUUD_W9gMM.Q0tz4agAdfIrxpHy2ua5uA2CBweH9T
 zIOXn9fCYkTd_DIN7YgwQHktr4nxV1yQt972b7AITeKOeBonlOyHBf2rvu8x9e0ShRP8aeAj_48n
 JRHwHOPYzZNrtCL8uvV6NnqutGtHNx6PMd9PXxZBNCV_JfCPBw8xQw5ZqmeNJ5P8dlYoyo7Gf5WP
 QQJ1JuZ39eFVWY41Sx33G.e4zCTt8RdeQAx3kpJlooz0dgBgTiP6HSfyvEQgWjnmDP0EOSuKeeJK
 DX5ttL___YDEd2z53NxPa8Hor60y.M8O869TRcbXLJ4ELkgE0EjAxkxJZ7XTiv07smahlfqaxouv
 q_omqjPfwea384biQ5QaUouaId5xWcItb9KafGfqu8G88FjvkY6dwtMEytUO_SJrVzRcgvZnuemE
 GaGpCN8al4t016ne8Ii2Mx4bWp8uqymewASQFIgiC.v3ThR0SjmLnwbhYAScJmCGDs1TmqsjRHHy
 _oFtPTZjV39tflr1EBB1k2dA73dmVb_EZdeYPqFNzg03MNDInQJ.P7YvxCiooBNtTd.atf1qUapU
 CyHwhd3_HFRGzSQBgmjfGQ6_UaChgSTxLxd4nXJrS7BQYIGN6.ld_oW2Cgd2VdbEYzRI7D3M.JqR
 j05LPkLWdx3ALnERr7TmL0yVbaLrL.PfKyx7iVkWdYkNI73FTmNIy48Xbcai0DrSj8Uy4_nkAiNx
 5oU3NzqHClPcXZOPfeT6Gvd477k3pqzGOhmfafakBJYuAtWYj8B7VNBJRGxgLxJIU.dj4vt1R8VY
 N70HZH3Vhqwm_Lc4WFt2kD2GLU2.jKiVla7RNEd3SnhO4zlzPb6AfpiY.iwg4mzjtzx6mJOxZvrK
 Sbo039y65PI9FGlI9jcWsigsUJTH5V3oVIUPbM6wp_HMZ6mhGznFlkURDCXM6A7EtGL4xnlqIOJ8
 EGZDMIgAdB7xp5CneeuGSoOv0myvYP6CAJ4DwZnDDuK8O9DeGZCEeWklcjODEcE7J5GG8Ui6nh_f
 m3447CZxwkhOod4ZmuLHwl82MyYegGPRPi5McfBCSv.8SvLKEQlSq7O6iAMSjDQ3Pvrt_fET8Oup
 eL0Q93ZZwxC1ThQTVYEKQvhMC85VlCkS0Pt5NI5DObhuS5Oy3cm4zrb7y3qGA5nXEXwWFozSEn8H
 SNs0BdQeuPenBr5OGV7dWl8H4NceaPQJaFHc00slQHcuh_GFS1QhxW3vk1O17fYSIefMvmQ2DgGK
 vxB5tMspqwZWwhDiNybvdolJGqBMg0bbKU8XdX60ql7Uz9xT4SNjMf3e960m1duB6n3jNgqAaC2k
 pz2x8q3nYgQjd9hnLXFfC7OIzQug3dYhiMy8O6zROG7PGVsuVUlfnIDmi.V_dsj1kY2QLkjvorcQ
 uGUrOscTeJrDe2Dregwv6Unhfp7Hl1TsZ1boDx1O.E9YRhDYu0AqKLfS11ZY7VB_HVGQpDooMpEn
 N.fj5lrrN2dsWtRMLNb2.4q6Lsj0uVMcsyqGD6ZDwrqg8jkUEuGuyY1m9lK_2rwiQN8yd_O_6EsU
 94XQsx7HuMuYxnH0woo55vHMbpgUT_UWVnUo2WM0XyK9aNw0cDTIc_H.gvCqksBelVWBTErm0.C4
 i1TtRtWhRnaqxLUaHqoByVg5eYWvkWtaCNbKlyn6OfWuM8pboXB2KCvpa8OC.it2o34u.39g1o3D
 kJxnVIx7Ir0t0jPpAQnWX4D.BM8LpgYzS4GczL.95HPjpXRsWJlWTW0JKYLC4mze0wUF_Wd_6kXG
 AOqlxJ7Q7162hFOpzdtshW_cL_jkqtLVkbI6gWDrcDjw738NTbHTFXqrPGb1hfWwXSMVtU3no4dP
 hCyRzqgCRwJQ2T7Y.0Lo0zTdAFzFCwbRnDb0QxYXNVMFXQ9uciuTGbbsU.2dOmcA156M3AUAWn_1
 TqvkWyA--
X-Sonic-MF: <lsatenstein@HIDDEN>
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic304.consmr.mail.ne1.yahoo.com with HTTP; Mon, 7 Jun 2021 02:00:55 +0000
Date: Mon, 7 Jun 2021 02:00:52 +0000 (UTC)
From: Leslie S Satenstein <lsatenstein@HIDDEN>
Message-ID: <39466090.4286189.1623031252971@HIDDEN>
In-Reply-To: <20210606054242.GI11733@HIDDEN>
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
 <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
 <20210604201630.GH11733@HIDDEN>
 <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
 <20210606054242.GI11733@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_4286188_894301194.1623031252967"
X-Mailer: WebService/1.1.18368 YMailNorrin
Content-Length: 43205
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

------=_Part_4286188_894301194.1623031252967
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I believe that /etc/fstab should not be subject to COW.=C2=A0 We can have p=
artitions dynamically mounted by users=20
(noauto,user on the fstab line).
/boot/efi must be protected as well.=C2=A0 Sometimes this directory is redi=
rected.=C2=A0 I have experienced cow issues with system reboots.=C2=A0 Then=
 running btrfs to defrag , the system can be rebooted.


Regards=20
=C2=A0Leslie
 Leslie Satenstein
Montr=C3=A9al Qu=C3=A9bec, Canada

=20

    On Sunday, June 6, 2021, 4:43:44 a.m. EDT, Zygo Blaxell <ce3g8jdj@umail=
.furryterror.org> wrote: =20
=20
 On Sat, Jun 05, 2021 at 01:56:49PM +0800, Tom Yan wrote:
> As far as I'm concerned, inheriting an attribute from the source inode
> isn't a "surprising" behavior. Rather it seems pretty "natural" to me.
> And I don't think whether the attribute is "dangerous" changes that,
> because if you consider it "dangerous", shouldn't you "watch out"
> anyway when you try to make a clone of a source with such an
> attribute?

It's important not to conflate the two contexts.=C2=A0 For cp -a, copying
attributes from the src inode might be obvious.=C2=A0 For any other applica=
tion
(including cp with different arguments), it might be the worst possible
thing to do, especially if we've been doing the opposite for over
a decade.

People run btrfs on crappy SSD and MMC devices, where filesystem csums
are the only way to know the disk is failing (SMART is nonexistent,
and the firmware doesn't bother with any form of working ECC or CRC, so
the first indication of any drive failure is when it starts corrupting
data).=C2=A0 Disabling the datasum bit on any inode is eventually equivalen=
t
to injecting a stream of random undetected corruption into the file when
the drive inevitably fails.=C2=A0 For users with such drives, a mount optio=
n
or filesystem feature flag to disable chattr +C globally would make sense,
as they never want any file to be nodatasum for any reason.

If cp -a implements the inode attribute propagation (or inheritance), then
only users of cp -a are impacted.=C2=A0 They are more likely to be aware th=
at
they may be creating new files with reduced-integrity storage attributes.

> If we see it from the way that, the kernel does not make the
> destination inherit nodatasum just to make reflink succeed as much as
> possible, but rather it just by design inherit nodatacow (for the
> reason of being NOT surprising), then there's no concern in whether
> they should "decoupled" when we implement the inheritance. (Like we
> can't set only nodatasum with `chattr either. It's simply out of the
> scope then.)

Thw window for design of these features mostly closed in 2008.=C2=A0 If we
limit the scope as you suggest, we stuck with a lot of the current
behavior now because it is existing kernel API.

If we also fixed some of the other design issues, like the invisible
datasum attribute, we could make the case that at least these automatic
implied inode changes would be _visible to users_.=C2=A0 At the moment,
it requires special tools to inspect the filesystem to see that a file
has its nodatasum bit set, and we probably don't want to start silently
flipping any more inode bits users can't even see.=C2=A0 We already did tha=
t
with prealloc and no-compression attributes, and users find it difficult
to understand the resulting changes in btrfs behavior.=C2=A0 There are some
proposals in the works to make all the inode flags visible as xattr
properties, and if those are done then we can say "well at least you
can see that we now change the datasum attribute sometimes."=C2=A0 But it's
a very weak argument.

The kernel has no way to know it's running 'cp -a' or that the intent
is to copy an existing object.=C2=A0 A user could be constructing a new
object using a combination of writes and reflinks from other files
(e.g. a disk image compiler) and intend for the result to have csums
even if the reflinked source files did not.

The kernel only knows that it has been told to create a file with XZ
attributes, and later the user requests cloning data from a file with
XYZ attributes.=C2=A0 If the user didn't intend for the dst file to have
XYZ attributes (and why would she, when she created the file with XZ
attributes?), then it could be a serious regression if the file suddenly
ends up with unintended Y attributes on new kernels.=C2=A0 Without easy
userspace visibility of the nodatasum attribute, it would be difficult
to even _detect_ this change until after silent data corruption gets
bad enough to be noticed.

Contrast with the coreutils package, which has changed its behavior
several times since reflink was first introduced in 2009 to adapt to
changing user expectations.=C2=A0 Nobody expects coreutils to behave quite
the same way from one year to the next, so there is room for innovation
there--and users who don't want the innovations can fork coreutils or
use some other tools.=C2=A0 One such innovation could be to simply detect
this case and make the appropriate inode changes before copying.

On the other hand, maybe nobody has any existing software deployed that
depends on the old kernel behavior, so we can change it after all.=C2=A0 In=
 the
dangerous case (cheap SSD), a sysadmin wouldn't have any nodatacow files
anywhere on the filesystem, so they wouldn't be making reflink copies
of them because none exist.=C2=A0 They could be making a copy of a nodataco=
w
file from another filesystem, but in that case they would be using normal
copy, since reflink doesn't work across filesystems.=C2=A0 Maybe we can fin=
d
all the users who are running reflinking disk image compilers and they
can update their code to work around the proposed new kernel behavior.

> I don't know if we can do that based on whether the reflink mode is
> always. Though we can fallback to "normal" copy when the source has
> nodatasum (and/or nodatacow), personally I don't find it less
> surprising than inheriting nodatacow all the time.

Note that the kernel never sees the reflink argument from cp.=C2=A0 It is
entirely implemented inside the 'cp' command.=C2=A0 In --reflink=3Dauto mod=
e,
cp will first try clone_range, and if the kernel rejects that with an
EINVAL error, then cp will try again with traditional read/write code.
This is after cp has already created the dst file.=C2=A0 The kernel does
not provide a "create a new file with the attributes of an old file"
call--cp has to create the file with open(), and then do a series of
chmod, chown, and setfattr calls in the right order to replicate the
attributes of the old file.

The kernel doesn't guarantee that reflinks are possible in all cases, and
generally does not provide any fallback.=C2=A0 There are multiple possible
responses to a reflink failure and the kernel cannot implement all
of them.=C2=A0 It is up to userspace (i.e. the cp command) to decide what a
correct fallback behavior should be, and then implement it.

> By the way, what will `chattr -C` do exactly if the file/inode had
> nodatacow? Is the behavior different when it is / there is a reflink?

If the file is empty, you can chattr +C or -C.=C2=A0 If the file is not
empty, chattr fails with an error.

All the data extents in a file have to have the same csum status (csum
present or csum absent) as the inode.=C2=A0 It is not allowed to change the
C attribute when data extents exist because the C attribute indirectly
affects whether the extents have data csums or not, and if the inode was
changed it would disagree with existing data extents.=C2=A0 If no data exte=
nts
exist (i.e. zero-length file), then the inode attribute can be changed,
because there is nothing present that could disagree with the inode.

It doesn't matter whether reflinks were previously made or not.=C2=A0 In bt=
rfs
there is no difference between a reflink and any other write, in the
same way that there is no difference between a directory entry created
by hardlink versus any other file creation.=C2=A0 Normal writes create a
new data extent, then reflink it to exactly the spot in file where the
data was written.=C2=A0 clone_range creates a reflink to some data extent(s=
)
that already exist.=C2=A0 Like hardlinks, when a reflink copy is made, it i=
s
not always possible to tell which was the original and which was the copy.

> On Sat, 5 Jun 2021 at 04:16, Zygo Blaxell
> <ce3g8jdj@HIDDEN> wrote:
> >
> > On Fri, Jun 04, 2021 at 10:37:35PM +0800, Tom Yan wrote:
> > > Also cc'ing bug-coreutils@HIDDEN
> > >
> > > On Fri, 4 Jun 2021 at 22:33, Tom Yan <tom.ty89@HIDDEN> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I've just bumped into a problem that I am not sure what the expecte=
d
> > > > behavior should be, but there seems to be something flawed.
> > > >
> > > > Say I have a file that was created with the No_COW attributed
> > > > (inherited from the directory / subvolume / mount option). Then if =
I
> > > > try to do a reflink copy, the copying will fail with "Invalid
> > > > argument" if the copy has no one to inherit the No_COW attribute fr=
om.
> >
> > Correct.=C2=A0 nodatacow implies nodatasum, and you cannot reflink an e=
xtent
> > from a nodatasum inode into a datasum inode.
> >
> > The result of allowing this would be a file that has some extents
> > that have csums, and some that do not.=C2=A0 Making this work would mak=
e
> > reading from such a file worse (i.e. make it slower, or fail to detect
> > corruption in metadata).=C2=A0 It's possible to solve some of those pro=
blems
> > (or at least contain them in inodes that are known to have mixed csum
> > and non-csum data), but first someone would have to make the case that
> > this is worth the effort to support.
> >
> > > > For example:
> > > > [tom@archlinux mnt]$ sudo btrfs subvol list .
> > > > ID 256 gen 11 top level 5 path a
> > > > ID 257 gen 9 top level 5 path b
> > > > [tom@archlinux mnt]$ lsattr
> > > > ---------------------- ./a
> > > > ---------------C------ ./b
> > > > [tom@archlinux mnt]$ lsattr b/
> > > > ---------------C------ b/test
> > > > [tom@archlinux mnt]$ du -h b/test
> > > > 512M=C2=A0 =C2=A0 b/test
> > > > [tom@archlinux mnt]$ lsattr a/
> > > > [tom@archlinux mnt]$ cp --reflink=3Dalways b/test a/
> > > > cp: failed to clone 'a/test' from 'b/test': Invalid argument
> > > > [tom@archlinux mnt]$ lsattr a/
> > > > ---------------------- a/test
> > > > [tom@archlinux mnt]$ du a/test
> > > > 0=C2=A0 =C2=A0 a/test
> > > > [tom@archlinux mnt]$ du --apparent-size a/test
> > > > 0=C2=A0 =C2=A0 a/test
> > > > [tom@archlinux mnt]$ rm a/test
> > > > [tom@archlinux mnt]$ sudo chattr +C a/
> > > > [tom@archlinux mnt]$ cp --reflink=3Dalways b/test a/
> > > > [tom@archlinux mnt]$ lsattr a/
> > > > ---------------C------ a/test
> > > > [tom@archlinux mnt]$ cmp b/test a/test
> > > > [tom@archlinux mnt]$
> > > >
> > > > I'm not entirely sure if a reflink copy is supposed to work for a
> > > > source file that was created with No_COW, but apparently it is.
> >
> > Snapshots are also allowed for nodatacow files.=C2=A0 The extents that =
are
> > shared become implicitly datacow until they are not shared any more.
> >
> > Snapshots are deferred reflink copies, so it would be difficult to
> > allow one and not the other.=C2=A0 Disallowing both seems overly restri=
ctive
> > (e.g. with such a restriction, it would not be possible to use 'btrfs
> > send' or make a snapshot on a subvol that contains any nodatacow file).
> >
> > btrfs did disallow both operations for swap files, so it could be possi=
ble
> > to disallow both reflinks and snapshots for nodatacow files, but AFAIK
> > nobody wants that (some people even want the swapfile restrictions to
> > go away someday).
> >
> > > > The
> > > > problem is just that the reflink copy also needs to have the attrib=
ute
> > > > set, yet it cannot inherit from the source automatically.
> >
> > reflink can only reflink copy from one nodatasum file to another nodata=
sum
> > file, or from one datasum file to another datasum file.
> >
> > An empty inode can be changed from datacow to nodatacow (or vice versa)
> > using the fsattr ioctl, which simultaneously changes the file from
> > datasum to nodatasum if the filesystem was not mounted with the nodatas=
um
> > mount option.
> >
> > There is a possible kernel enhancement here:=C2=A0 when an empty inode =
is the
> > dst of a reflink, automatically change the reflink dst inode's nodatasu=
m
> > flag to match the reflink src inode's nodatasum flag.=C2=A0 If the dst =
inode
> > is not empty and the inode datasum flags do not match, then reject the
> > reflink with EINVAL as before.
> >
> > It's not clear whether this should apply only to nodatasum or also to
> > nodatacow.=C2=A0 reflink doesn't need src and dst agreement on nodataco=
w,
> > so the dst inode could be a nodatasum+datacow file.=C2=A0 Unfortunately=
 all
> > the userspace tools including coreutils can only see the nodatacow
> > inode bit, not the nodatasum bit, so the lack of csums on the dst file
> > would be invisible.=C2=A0 The kernel cannot know the user's intent from=
 the
> > available information.
> >
> > It's not clear that we want the kernel to be implicitly changing
> > inode attribute bits like this--especially bits that disable integrity
> > features like nodatasum.=C2=A0 There is precedent for changing fsattrs =
with
> > the no-compress inode flag, but that flag doesn't disable csums, and
> > this one would.
> >
> > One could also make the opposite case:=C2=A0 it should always be an err=
or to
> > do anything that would put data in a datasum file without csums, the
> > existing behavior is correct, and should not be changed.=C2=A0 The prob=
lem
> > with this argument is that users can't see the datasum inode bits,
> > so it's not clear that the EINVAL is a data protection mechanism.
> >
> > > > I wonder if this is a kernel-side problem or something that coreuti=
ls
> > > > missed? It also seems wrong that when it fails there will be an emp=
ty
> > > > destination file created.
> >
> > Normally coreutils will fall back to simple copy if --reflink=3Dauto
> > is used.=C2=A0 --reflink=3Dalways is the user's explicit request for "r=
eflink
> > or nothing, please."=C2=A0 The user correctly got nothing, as requested=
.
> >
> > On other filesystems, reflink on a nodatacow file might make a simple
> > copy in the kernel--in which case you are no better off than if you had
> > used --reflink=3Dauto.
> >
> > coreutils could propagate the source inode nodatacow fsattribute to
> > the destination inode if it intends to use reflink to copy the data.
> > That would be the userspace equivalent of the kernel enhancement I
> > suggested above.=C2=A0 It would probably match user expectations better=
--no
> > hidden surprises for non-coreutils use cases, and all the affected inod=
e
> > attribute bits are necessarily visible in userspace.
> >
> > fsattr propagation could be quite complicated for coreutils to implemen=
t
> > correctly in general, as some fsattrs should not be propagated this way=
,
> > and other filesystems may have different restrictions.=C2=A0 Some fsatt=
rs must
> > be set before the data is written (e.g. -c for compression), others mus=
t
> > be set after the data is written (e.g. -i for immutable), and some are
> > a matter of user intent (e.g. should a simple copy be compressed if the
> > source is not?=C2=A0 Depends on the intended use of the copy).
> >
> > On other filesystems this userspace behavior might trigger the opposite
> > of the intended kernel behavior, causing reflink to always fall back to
> > simple copy because the dst inode's nodatacow attribute is set.
> >
> > Ideally btrfs will not force coreutils to do one thing on btrfs and the
> > opposite thing on other filesystems, so it might be worthwhile to hack
> > around this in the kernel as proposed above.=C2=A0 There is precedent f=
or
> > that--btrfs falls back to simple copy in reflinks of inline extents,
> > more or less for the sole purpose of making cp --reflink=3Dalways not f=
ail
> > so randomly.
> >
> > > > Kernel version: Linux archlinux 5.12.8-arch1-1 #1 SMP PREEMPT Fri, =
28
> > > > May 2021 15:10:20 +0000 x86_64 GNU/Linux
> > > > Coreutils version: 8.32
> > > >
> > > > Regards,
> > > > Tom



 =20
------=_Part_4286188_894301194.1623031252967
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div class=3D"ydpe2616bf0yahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px=
;"><div><div dir=3D"ltr" data-setdir=3D"false">I believe that /etc/fstab sh=
ould not be subject to COW.&nbsp; We can have partitions dynamically mounte=
d by users <br></div><div dir=3D"ltr" data-setdir=3D"false">(noauto,user on=
 the fstab line).</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><di=
v dir=3D"ltr" data-setdir=3D"false">/boot/efi must be protected as well.&nb=
sp; Sometimes this directory is redirected.&nbsp; I have experienced cow is=
sues with system reboots.&nbsp; Then running btrfs to defrag , the system c=
an be rebooted.</div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div =
dir=3D"ltr" data-setdir=3D"false"><br></div><div><br></div><div class=3D"yd=
pe2616bf0signature"><div><div><div><div><div><div><div><span lang=3D"FR-CA"=
>Regards</span>  <div><b><font size=3D"2"><br></font><font size=3D"2">&nbsp=
;Leslie</font><br></b></div> <div><font color=3D"green"><b><font size=3D"1"=
>Leslie Satenstein</font></b></font><font style=3D"color:rgb(191, 0, 95);" =
size=3D"1" color=3D"green"><span style=3D"font-weight:bold;"></span></font>=
<br></div><font size=3D"2" color=3D"green"><b>Montr=C3=A9al Qu=C3=A9bec, Ca=
nada</b><br></font><br><font size=3D"1" face=3D"lucida console, sans-serif"=
><b id=3D"ydpe2616bf0yui_3_13_0_ym1_1_1391351152837_28311"><font id=3D"ydpe=
2616bf0yui_3_13_0_ym1_1_1391351152837_28310" color=3D"black"><span id=3D"yd=
pe2616bf0yui_3_13_0_ym1_1_1391351152837_28309" style=3D"font-weight:bold;fo=
nt-size:13.5pt;color:black;"></span></font></b></font></div></div></div></d=
iv></div></div></div></div></div>
        <div><br></div><div><br></div>
       =20
        </div><div id=3D"ydpc369ab51yahoo_quoted_3575257451" class=3D"ydpc3=
69ab51yahoo_quoted">
            <div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
               =20
                <div>
                    On Sunday, June 6, 2021, 4:43:44 a.m. EDT, Zygo Blaxell=
 &lt;ce3g8jdj@HIDDEN&gt; wrote:
                </div>
                <div><br></div>
                <div><br></div>
                <div>On Sat, Jun 05, 2021 at 01:56:49PM +0800, Tom Yan wrot=
e:<br clear=3D"none">&gt; As far as I'm concerned, inheriting an attribute =
from the source inode<br clear=3D"none">&gt; isn't a "surprising" behavior.=
 Rather it seems pretty "natural" to me.<br clear=3D"none">&gt; And I don't=
 think whether the attribute is "dangerous" changes that,<br clear=3D"none"=
>&gt; because if you consider it "dangerous", shouldn't you "watch out"<br =
clear=3D"none">&gt; anyway when you try to make a clone of a source with su=
ch an<br clear=3D"none">&gt; attribute?<br clear=3D"none"><br clear=3D"none=
">It's important not to conflate the two contexts.&nbsp; For cp -a, copying=
<br clear=3D"none">attributes from the src inode might be obvious.&nbsp; Fo=
r any other application<br clear=3D"none">(including cp with different argu=
ments), it might be the worst possible<br clear=3D"none">thing to do, espec=
ially if we've been doing the opposite for over<br clear=3D"none">a decade.=
<br clear=3D"none"><br clear=3D"none">People run btrfs on crappy SSD and MM=
C devices, where filesystem csums<br clear=3D"none">are the only way to kno=
w the disk is failing (SMART is nonexistent,<br clear=3D"none">and the firm=
ware doesn't bother with any form of working ECC or CRC, so<br clear=3D"non=
e">the first indication of any drive failure is when it starts corrupting<b=
r clear=3D"none">data).&nbsp; Disabling the datasum bit on any inode is eve=
ntually equivalent<br clear=3D"none">to injecting a stream of random undete=
cted corruption into the file when<br clear=3D"none">the drive inevitably f=
ails.&nbsp; For users with such drives, a mount option<br clear=3D"none">or=
 filesystem feature flag to disable chattr +C globally would make sense,<br=
 clear=3D"none">as they never want any file to be nodatasum for any reason.=
<br clear=3D"none"><br clear=3D"none">If cp -a implements the inode attribu=
te propagation (or inheritance), then<br clear=3D"none">only users of cp -a=
 are impacted.&nbsp; They are more likely to be aware that<br clear=3D"none=
">they may be creating new files with reduced-integrity storage attributes.=
<br clear=3D"none"><br clear=3D"none">&gt; If we see it from the way that, =
the kernel does not make the<br clear=3D"none">&gt; destination inherit nod=
atasum just to make reflink succeed as much as<br clear=3D"none">&gt; possi=
ble, but rather it just by design inherit nodatacow (for the<br clear=3D"no=
ne">&gt; reason of being NOT surprising), then there's no concern in whethe=
r<br clear=3D"none">&gt; they should "decoupled" when we implement the inhe=
ritance. (Like we<br clear=3D"none">&gt; can't set only nodatasum with `cha=
ttr either. It's simply out of the<br clear=3D"none">&gt; scope then.)<br c=
lear=3D"none"><br clear=3D"none">Thw window for design of these features mo=
stly closed in 2008.&nbsp; If we<br clear=3D"none">limit the scope as you s=
uggest, we stuck with a lot of the current<br clear=3D"none">behavior now b=
ecause it is existing kernel API.<br clear=3D"none"><br clear=3D"none">If w=
e also fixed some of the other design issues, like the invisible<br clear=
=3D"none">datasum attribute, we could make the case that at least these aut=
omatic<br clear=3D"none">implied inode changes would be _visible to users_.=
&nbsp; At the moment,<br clear=3D"none">it requires special tools to inspec=
t the filesystem to see that a file<br clear=3D"none">has its nodatasum bit=
 set, and we probably don't want to start silently<br clear=3D"none">flippi=
ng any more inode bits users can't even see.&nbsp; We already did that<br c=
lear=3D"none">with prealloc and no-compression attributes, and users find i=
t difficult<br clear=3D"none">to understand the resulting changes in btrfs =
behavior.&nbsp; There are some<br clear=3D"none">proposals in the works to =
make all the inode flags visible as xattr<br clear=3D"none">properties, and=
 if those are done then we can say "well at least you<br clear=3D"none">can=
 see that we now change the datasum attribute sometimes."&nbsp; But it's<br=
 clear=3D"none">a very weak argument.<br clear=3D"none"><br clear=3D"none">=
The kernel has no way to know it's running 'cp -a' or that the intent<br cl=
ear=3D"none">is to copy an existing object.&nbsp; A user could be construct=
ing a new<br clear=3D"none">object using a combination of writes and reflin=
ks from other files<br clear=3D"none">(e.g. a disk image compiler) and inte=
nd for the result to have csums<br clear=3D"none">even if the reflinked sou=
rce files did not.<br clear=3D"none"><br clear=3D"none">The kernel only kno=
ws that it has been told to create a file with XZ<br clear=3D"none">attribu=
tes, and later the user requests cloning data from a file with<br clear=3D"=
none">XYZ attributes.&nbsp; If the user didn't intend for the dst file to h=
ave<br clear=3D"none">XYZ attributes (and why would she, when she created t=
he file with XZ<br clear=3D"none">attributes?), then it could be a serious =
regression if the file suddenly<br clear=3D"none">ends up with unintended Y=
 attributes on new kernels.&nbsp; Without easy<br clear=3D"none">userspace =
visibility of the nodatasum attribute, it would be difficult<br clear=3D"no=
ne">to even _detect_ this change until after silent data corruption gets<br=
 clear=3D"none">bad enough to be noticed.<br clear=3D"none"><br clear=3D"no=
ne">Contrast with the coreutils package, which has changed its behavior<br =
clear=3D"none">several times since reflink was first introduced in 2009 to =
adapt to<br clear=3D"none">changing user expectations.&nbsp; Nobody expects=
 coreutils to behave quite<br clear=3D"none">the same way from one year to =
the next, so there is room for innovation<br clear=3D"none">there--and user=
s who don't want the innovations can fork coreutils or<br clear=3D"none">us=
e some other tools.&nbsp; One such innovation could be to simply detect<br =
clear=3D"none">this case and make the appropriate inode changes before copy=
ing.<br clear=3D"none"><br clear=3D"none">On the other hand, maybe nobody h=
as any existing software deployed that<br clear=3D"none">depends on the old=
 kernel behavior, so we can change it after all.&nbsp; In the<br clear=3D"n=
one">dangerous case (cheap SSD), a sysadmin wouldn't have any nodatacow fil=
es<br clear=3D"none">anywhere on the filesystem, so they wouldn't be making=
 reflink copies<br clear=3D"none">of them because none exist.&nbsp; They co=
uld be making a copy of a nodatacow<br clear=3D"none">file from another fil=
esystem, but in that case they would be using normal<br clear=3D"none">copy=
, since reflink doesn't work across filesystems.&nbsp; Maybe we can find<br=
 clear=3D"none">all the users who are running reflinking disk image compile=
rs and they<br clear=3D"none">can update their code to work around the prop=
osed new kernel behavior.<br clear=3D"none"><br clear=3D"none">&gt; I don't=
 know if we can do that based on whether the reflink mode is<br clear=3D"no=
ne">&gt; always. Though we can fallback to "normal" copy when the source ha=
s<br clear=3D"none">&gt; nodatasum (and/or nodatacow), personally I don't f=
ind it less<br clear=3D"none">&gt; surprising than inheriting nodatacow all=
 the time.<br clear=3D"none"><br clear=3D"none">Note that the kernel never =
sees the reflink argument from cp.&nbsp; It is<br clear=3D"none">entirely i=
mplemented inside the 'cp' command.&nbsp; In --reflink=3Dauto mode,<br clea=
r=3D"none">cp will first try clone_range, and if the kernel rejects that wi=
th an<br clear=3D"none">EINVAL error, then cp will try again with tradition=
al read/write code.<br clear=3D"none">This is after cp has already created =
the dst file.&nbsp; The kernel does<br clear=3D"none">not provide a "create=
 a new file with the attributes of an old file"<br clear=3D"none">call--cp =
has to create the file with open(), and then do a series of<br clear=3D"non=
e">chmod, chown, and setfattr calls in the right order to replicate the<br =
clear=3D"none">attributes of the old file.<br clear=3D"none"><br clear=3D"n=
one">The kernel doesn't guarantee that reflinks are possible in all cases, =
and<br clear=3D"none">generally does not provide any fallback.&nbsp; There =
are multiple possible<br clear=3D"none">responses to a reflink failure and =
the kernel cannot implement all<br clear=3D"none">of them.&nbsp; It is up t=
o userspace (i.e. the cp command) to decide what a<br clear=3D"none">correc=
t fallback behavior should be, and then implement it.<br clear=3D"none"><br=
 clear=3D"none">&gt; By the way, what will `chattr -C` do exactly if the fi=
le/inode had<br clear=3D"none">&gt; nodatacow? Is the behavior different wh=
en it is / there is a reflink?<br clear=3D"none"><br clear=3D"none">If the =
file is empty, you can chattr +C or -C.&nbsp; If the file is not<br clear=
=3D"none">empty, chattr fails with an error.<br clear=3D"none"><br clear=3D=
"none">All the data extents in a file have to have the same csum status (cs=
um<br clear=3D"none">present or csum absent) as the inode.&nbsp; It is not =
allowed to change the<br clear=3D"none">C attribute when data extents exist=
 because the C attribute indirectly<br clear=3D"none">affects whether the e=
xtents have data csums or not, and if the inode was<br clear=3D"none">chang=
ed it would disagree with existing data extents.&nbsp; If no data extents<b=
r clear=3D"none">exist (i.e. zero-length file), then the inode attribute ca=
n be changed,<br clear=3D"none">because there is nothing present that could=
 disagree with the inode.<br clear=3D"none"><br clear=3D"none">It doesn't m=
atter whether reflinks were previously made or not.&nbsp; In btrfs<br clear=
=3D"none">there is no difference between a reflink and any other write, in =
the<br clear=3D"none">same way that there is no difference between a direct=
ory entry created<br clear=3D"none">by hardlink versus any other file creat=
ion.&nbsp; Normal writes create a<br clear=3D"none">new data extent, then r=
eflink it to exactly the spot in file where the<br clear=3D"none">data was =
written.&nbsp; clone_range creates a reflink to some data extent(s)<br clea=
r=3D"none">that already exist.&nbsp; Like hardlinks, when a reflink copy is=
 made, it is<br clear=3D"none">not always possible to tell which was the or=
iginal and which was the copy.<div class=3D"ydpc369ab51yqt7672869828" id=3D=
"ydpc369ab51yqtfd89377"><br clear=3D"none"><br clear=3D"none">&gt; On Sat, =
5 Jun 2021 at 04:16, Zygo Blaxell<br clear=3D"none">&gt; &lt;<a shape=3D"re=
ct" href=3D"mailto:ce3g8jdj@HIDDEN" rel=3D"nofollow" target=
=3D"_blank">ce3g8jdj@HIDDEN</a>&gt; wrote:<br clear=3D"none"=
>&gt; &gt;<br clear=3D"none">&gt; &gt; On Fri, Jun 04, 2021 at 10:37:35PM +=
0800, Tom Yan wrote:<br clear=3D"none">&gt; &gt; &gt; Also cc'ing <a shape=
=3D"rect" href=3D"mailto:bug-coreutils@HIDDEN" rel=3D"nofollow" target=3D=
"_blank">bug-coreutils@HIDDEN</a><br clear=3D"none">&gt; &gt; &gt;<br cle=
ar=3D"none">&gt; &gt; &gt; On Fri, 4 Jun 2021 at 22:33, Tom Yan &lt;<a shap=
e=3D"rect" href=3D"mailto:tom.ty89@HIDDEN" rel=3D"nofollow" target=3D"_b=
lank">tom.ty89@HIDDEN</a>&gt; wrote:<br clear=3D"none">&gt; &gt; &gt; &g=
t;<br clear=3D"none">&gt; &gt; &gt; &gt; Hi all,<br clear=3D"none">&gt; &gt=
; &gt; &gt;<br clear=3D"none">&gt; &gt; &gt; &gt; I've just bumped into a p=
roblem that I am not sure what the expected<br clear=3D"none">&gt; &gt; &gt=
; &gt; behavior should be, but there seems to be something flawed.<br clear=
=3D"none">&gt; &gt; &gt; &gt;<br clear=3D"none">&gt; &gt; &gt; &gt; Say I h=
ave a file that was created with the No_COW attributed<br clear=3D"none">&g=
t; &gt; &gt; &gt; (inherited from the directory / subvolume / mount option)=
. Then if I<br clear=3D"none">&gt; &gt; &gt; &gt; try to do a reflink copy,=
 the copying will fail with "Invalid<br clear=3D"none">&gt; &gt; &gt; &gt; =
argument" if the copy has no one to inherit the No_COW attribute from.<br c=
lear=3D"none">&gt; &gt;<br clear=3D"none">&gt; &gt; Correct.&nbsp; nodataco=
w implies nodatasum, and you cannot reflink an extent<br clear=3D"none">&gt=
; &gt; from a nodatasum inode into a datasum inode.<br clear=3D"none">&gt; =
&gt;<br clear=3D"none">&gt; &gt; The result of allowing this would be a fil=
e that has some extents<br clear=3D"none">&gt; &gt; that have csums, and so=
me that do not.&nbsp; Making this work would make<br clear=3D"none">&gt; &g=
t; reading from such a file worse (i.e. make it slower, or fail to detect<b=
r clear=3D"none">&gt; &gt; corruption in metadata).&nbsp; It's possible to =
solve some of those problems<br clear=3D"none">&gt; &gt; (or at least conta=
in them in inodes that are known to have mixed csum<br clear=3D"none">&gt; =
&gt; and non-csum data), but first someone would have to make the case that=
<br clear=3D"none">&gt; &gt; this is worth the effort to support.<br clear=
=3D"none">&gt; &gt;<br clear=3D"none">&gt; &gt; &gt; &gt; For example:<br c=
lear=3D"none">&gt; &gt; &gt; &gt; [<a shape=3D"rect" href=3D"mailto:tom@arc=
hlinux" rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ sudo btr=
fs subvol list .<br clear=3D"none">&gt; &gt; &gt; &gt; ID 256 gen 11 top le=
vel 5 path a<br clear=3D"none">&gt; &gt; &gt; &gt; ID 257 gen 9 top level 5=
 path b<br clear=3D"none">&gt; &gt; &gt; &gt; [<a shape=3D"rect" href=3D"ma=
ilto:tom@archlinux" rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mn=
t]$ lsattr<br clear=3D"none">&gt; &gt; &gt; &gt; ---------------------- ./a=
<br clear=3D"none">&gt; &gt; &gt; &gt; ---------------C------ ./b<br clear=
=3D"none">&gt; &gt; &gt; &gt; [<a shape=3D"rect" href=3D"mailto:tom@archlin=
ux" rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ lsattr b/<br=
 clear=3D"none">&gt; &gt; &gt; &gt; ---------------C------ b/test<br clear=
=3D"none">&gt; &gt; &gt; &gt; [<a shape=3D"rect" href=3D"mailto:tom@archlin=
ux" rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ du -h b/test=
<br clear=3D"none">&gt; &gt; &gt; &gt; 512M&nbsp; &nbsp; b/test<br clear=3D=
"none">&gt; &gt; &gt; &gt; [<a shape=3D"rect" href=3D"mailto:tom@archlinux"=
 rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ lsattr a/<br cl=
ear=3D"none">&gt; &gt; &gt; &gt; [<a shape=3D"rect" href=3D"mailto:tom@arch=
linux" rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ cp --refl=
ink=3Dalways b/test a/<br clear=3D"none">&gt; &gt; &gt; &gt; cp: failed to =
clone 'a/test' from 'b/test': Invalid argument<br clear=3D"none">&gt; &gt; =
&gt; &gt; [<a shape=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofollow"=
 target=3D"_blank">tom@archlinux</a> mnt]$ lsattr a/<br clear=3D"none">&gt;=
 &gt; &gt; &gt; ---------------------- a/test<br clear=3D"none">&gt; &gt; &=
gt; &gt; [<a shape=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofollow" =
target=3D"_blank">tom@archlinux</a> mnt]$ du a/test<br clear=3D"none">&gt; =
&gt; &gt; &gt; 0&nbsp; &nbsp; a/test<br clear=3D"none">&gt; &gt; &gt; &gt; =
[<a shape=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofollow" target=3D=
"_blank">tom@archlinux</a> mnt]$ du --apparent-size a/test<br clear=3D"none=
">&gt; &gt; &gt; &gt; 0&nbsp; &nbsp; a/test<br clear=3D"none">&gt; &gt; &gt=
; &gt; [<a shape=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofollow" ta=
rget=3D"_blank">tom@archlinux</a> mnt]$ rm a/test<br clear=3D"none">&gt; &g=
t; &gt; &gt; [<a shape=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofoll=
ow" target=3D"_blank">tom@archlinux</a> mnt]$ sudo chattr +C a/<br clear=3D=
"none">&gt; &gt; &gt; &gt; [<a shape=3D"rect" href=3D"mailto:tom@archlinux"=
 rel=3D"nofollow" target=3D"_blank">tom@archlinux</a> mnt]$ cp --reflink=3D=
always b/test a/<br clear=3D"none">&gt; &gt; &gt; &gt; [<a shape=3D"rect" h=
ref=3D"mailto:tom@archlinux" rel=3D"nofollow" target=3D"_blank">tom@archlin=
ux</a> mnt]$ lsattr a/<br clear=3D"none">&gt; &gt; &gt; &gt; --------------=
-C------ a/test<br clear=3D"none">&gt; &gt; &gt; &gt; [<a shape=3D"rect" hr=
ef=3D"mailto:tom@archlinux" rel=3D"nofollow" target=3D"_blank">tom@archlinu=
x</a> mnt]$ cmp b/test a/test<br clear=3D"none">&gt; &gt; &gt; &gt; [<a sha=
pe=3D"rect" href=3D"mailto:tom@archlinux" rel=3D"nofollow" target=3D"_blank=
">tom@archlinux</a> mnt]$<br clear=3D"none">&gt; &gt; &gt; &gt;<br clear=3D=
"none">&gt; &gt; &gt; &gt; I'm not entirely sure if a reflink copy is suppo=
sed to work for a<br clear=3D"none">&gt; &gt; &gt; &gt; source file that wa=
s created with No_COW, but apparently it is.<br clear=3D"none">&gt; &gt;<br=
 clear=3D"none">&gt; &gt; Snapshots are also allowed for nodatacow files.&n=
bsp; The extents that are<br clear=3D"none">&gt; &gt; shared become implici=
tly datacow until they are not shared any more.<br clear=3D"none">&gt; &gt;=
<br clear=3D"none">&gt; &gt; Snapshots are deferred reflink copies, so it w=
ould be difficult to<br clear=3D"none">&gt; &gt; allow one and not the othe=
r.&nbsp; Disallowing both seems overly restrictive<br clear=3D"none">&gt; &=
gt; (e.g. with such a restriction, it would not be possible to use 'btrfs<b=
r clear=3D"none">&gt; &gt; send' or make a snapshot on a subvol that contai=
ns any nodatacow file).<br clear=3D"none">&gt; &gt;<br clear=3D"none">&gt; =
&gt; btrfs did disallow both operations for swap files, so it could be poss=
ible<br clear=3D"none">&gt; &gt; to disallow both reflinks and snapshots fo=
r nodatacow files, but AFAIK<br clear=3D"none">&gt; &gt; nobody wants that =
(some people even want the swapfile restrictions to<br clear=3D"none">&gt; =
&gt; go away someday).<br clear=3D"none">&gt; &gt;<br clear=3D"none">&gt; &=
gt; &gt; &gt; The<br clear=3D"none">&gt; &gt; &gt; &gt; problem is just tha=
t the reflink copy also needs to have the attribute<br clear=3D"none">&gt; =
&gt; &gt; &gt; set, yet it cannot inherit from the source automatically.<br=
 clear=3D"none">&gt; &gt;<br clear=3D"none">&gt; &gt; reflink can only refl=
ink copy from one nodatasum file to another nodatasum<br clear=3D"none">&gt=
; &gt; file, or from one datasum file to another datasum file.<br clear=3D"=
none">&gt; &gt;<br clear=3D"none">&gt; &gt; An empty inode can be changed f=
rom datacow to nodatacow (or vice versa)<br clear=3D"none">&gt; &gt; using =
the fsattr ioctl, which simultaneously changes the file from<br clear=3D"no=
ne">&gt; &gt; datasum to nodatasum if the filesystem was not mounted with t=
he nodatasum<br clear=3D"none">&gt; &gt; mount option.<br clear=3D"none">&g=
t; &gt;<br clear=3D"none">&gt; &gt; There is a possible kernel enhancement =
here:&nbsp; when an empty inode is the<br clear=3D"none">&gt; &gt; dst of a=
 reflink, automatically change the reflink dst inode's nodatasum<br clear=
=3D"none">&gt; &gt; flag to match the reflink src inode's nodatasum flag.&n=
bsp; If the dst inode<br clear=3D"none">&gt; &gt; is not empty and the inod=
e datasum flags do not match, then reject the<br clear=3D"none">&gt; &gt; r=
eflink with EINVAL as before.<br clear=3D"none">&gt; &gt;<br clear=3D"none"=
>&gt; &gt; It's not clear whether this should apply only to nodatasum or al=
so to<br clear=3D"none">&gt; &gt; nodatacow.&nbsp; reflink doesn't need src=
 and dst agreement on nodatacow,<br clear=3D"none">&gt; &gt; so the dst ino=
de could be a nodatasum+datacow file.&nbsp; Unfortunately all<br clear=3D"n=
one">&gt; &gt; the userspace tools including coreutils can only see the nod=
atacow<br clear=3D"none">&gt; &gt; inode bit, not the nodatasum bit, so the=
 lack of csums on the dst file<br clear=3D"none">&gt; &gt; would be invisib=
le.&nbsp; The kernel cannot know the user's intent from the<br clear=3D"non=
e">&gt; &gt; available information.<br clear=3D"none">&gt; &gt;<br clear=3D=
"none">&gt; &gt; It's not clear that we want the kernel to be implicitly ch=
anging<br clear=3D"none">&gt; &gt; inode attribute bits like this--especial=
ly bits that disable integrity<br clear=3D"none">&gt; &gt; features like no=
datasum.&nbsp; There is precedent for changing fsattrs with<br clear=3D"non=
e">&gt; &gt; the no-compress inode flag, but that flag doesn't disable csum=
s, and<br clear=3D"none">&gt; &gt; this one would.<br clear=3D"none">&gt; &=
gt;<br clear=3D"none">&gt; &gt; One could also make the opposite case:&nbsp=
; it should always be an error to<br clear=3D"none">&gt; &gt; do anything t=
hat would put data in a datasum file without csums, the<br clear=3D"none">&=
gt; &gt; existing behavior is correct, and should not be changed.&nbsp; The=
 problem<br clear=3D"none">&gt; &gt; with this argument is that users can't=
 see the datasum inode bits,<br clear=3D"none">&gt; &gt; so it's not clear =
that the EINVAL is a data protection mechanism.<br clear=3D"none">&gt; &gt;=
<br clear=3D"none">&gt; &gt; &gt; &gt; I wonder if this is a kernel-side pr=
oblem or something that coreutils<br clear=3D"none">&gt; &gt; &gt; &gt; mis=
sed? It also seems wrong that when it fails there will be an empty<br clear=
=3D"none">&gt; &gt; &gt; &gt; destination file created.<br clear=3D"none">&=
gt; &gt;<br clear=3D"none">&gt; &gt; Normally coreutils will fall back to s=
imple copy if --reflink=3Dauto<br clear=3D"none">&gt; &gt; is used.&nbsp; -=
-reflink=3Dalways is the user's explicit request for "reflink<br clear=3D"n=
one">&gt; &gt; or nothing, please."&nbsp; The user correctly got nothing, a=
s requested.<br clear=3D"none">&gt; &gt;<br clear=3D"none">&gt; &gt; On oth=
er filesystems, reflink on a nodatacow file might make a simple<br clear=3D=
"none">&gt; &gt; copy in the kernel--in which case you are no better off th=
an if you had<br clear=3D"none">&gt; &gt; used --reflink=3Dauto.<br clear=
=3D"none">&gt; &gt;<br clear=3D"none">&gt; &gt; coreutils could propagate t=
he source inode nodatacow fsattribute to<br clear=3D"none">&gt; &gt; the de=
stination inode if it intends to use reflink to copy the data.<br clear=3D"=
none">&gt; &gt; That would be the userspace equivalent of the kernel enhanc=
ement I<br clear=3D"none">&gt; &gt; suggested above.&nbsp; It would probabl=
y match user expectations better--no<br clear=3D"none">&gt; &gt; hidden sur=
prises for non-coreutils use cases, and all the affected inode<br clear=3D"=
none">&gt; &gt; attribute bits are necessarily visible in userspace.<br cle=
ar=3D"none">&gt; &gt;<br clear=3D"none">&gt; &gt; fsattr propagation could =
be quite complicated for coreutils to implement<br clear=3D"none">&gt; &gt;=
 correctly in general, as some fsattrs should not be propagated this way,<b=
r clear=3D"none">&gt; &gt; and other filesystems may have different restric=
tions.&nbsp; Some fsattrs must<br clear=3D"none">&gt; &gt; be set before th=
e data is written (e.g. -c for compression), others must<br clear=3D"none">=
&gt; &gt; be set after the data is written (e.g. -i for immutable), and som=
e are<br clear=3D"none">&gt; &gt; a matter of user intent (e.g. should a si=
mple copy be compressed if the<br clear=3D"none">&gt; &gt; source is not?&n=
bsp; Depends on the intended use of the copy).<br clear=3D"none">&gt; &gt;<=
br clear=3D"none">&gt; &gt; On other filesystems this userspace behavior mi=
ght trigger the opposite<br clear=3D"none">&gt; &gt; of the intended kernel=
 behavior, causing reflink to always fall back to<br clear=3D"none">&gt; &g=
t; simple copy because the dst inode's nodatacow attribute is set.<br clear=
=3D"none">&gt; &gt;<br clear=3D"none">&gt; &gt; Ideally btrfs will not forc=
e coreutils to do one thing on btrfs and the<br clear=3D"none">&gt; &gt; op=
posite thing on other filesystems, so it might be worthwhile to hack<br cle=
ar=3D"none">&gt; &gt; around this in the kernel as proposed above.&nbsp; Th=
ere is precedent for<br clear=3D"none">&gt; &gt; that--btrfs falls back to =
simple copy in reflinks of inline extents,<br clear=3D"none">&gt; &gt; more=
 or less for the sole purpose of making cp --reflink=3Dalways not fail<br c=
lear=3D"none">&gt; &gt; so randomly.<br clear=3D"none">&gt; &gt;<br clear=
=3D"none">&gt; &gt; &gt; &gt; Kernel version: Linux archlinux 5.12.8-arch1-=
1 #1 SMP PREEMPT Fri, 28<br clear=3D"none">&gt; &gt; &gt; &gt; May 2021 15:=
10:20 +0000 x86_64 GNU/Linux<br clear=3D"none">&gt; &gt; &gt; &gt; Coreutil=
s version: 8.32<br clear=3D"none">&gt; &gt; &gt; &gt;<br clear=3D"none">&gt=
; &gt; &gt; &gt; Regards,<br clear=3D"none">&gt; &gt; &gt; &gt; Tom<br clea=
r=3D"none"><br clear=3D"none"><br clear=3D"none"><br clear=3D"none"></div><=
/div>
            </div>
        </div></body></html>
------=_Part_4286188_894301194.1623031252967--

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
Resent-From: Paul Eggert <eggert@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 07 Jun 2021 05:48:01 +0000
Resent-Message-ID: <handler.48833.B48833.162304483724971 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 48833
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Zygo Blaxell <ce3g8jdj@HIDDEN>, Tom Yan <tom.ty89@HIDDEN>
Cc: 48833 <at> debbugs.gnu.org, linux-btrfs@HIDDEN
Received: via spool by 48833-submit <at> debbugs.gnu.org id=B48833.162304483724971
          (code B ref 48833); Mon, 07 Jun 2021 05:48:01 +0000
Received: (at 48833) by debbugs.gnu.org; 7 Jun 2021 05:47:17 +0000
Received: from localhost ([127.0.0.1]:54307 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lq86X-0006Uh-BN
	for submit <at> debbugs.gnu.org; Mon, 07 Jun 2021 01:47:17 -0400
Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59658)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eggert@HIDDEN>) id 1lq86T-0006UO-Ta
 for 48833 <at> debbugs.gnu.org; Mon, 07 Jun 2021 01:47:16 -0400
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id BBC7516005E;
 Sun,  6 Jun 2021 22:47:07 -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 94233WHieqS7; Sun,  6 Jun 2021 22:47:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
 by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1200C160064;
 Sun,  6 Jun 2021 22:47:07 -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 rU0UWHVL2jpA; Sun,  6 Jun 2021 22:47:06 -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 D5E9116005E;
 Sun,  6 Jun 2021 22:47:06 -0700 (PDT)
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
 <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
 <20210604201630.GH11733@HIDDEN>
 <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
 <20210606054242.GI11733@HIDDEN>
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
Message-ID: <4354c814-9f9f-0c26-fb11-36567da6f530@HIDDEN>
Date: Sun, 6 Jun 2021 22:47:05 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <20210606054242.GI11733@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

On 6/5/21 10:42 PM, Zygo Blaxell wrote:
> If cp -a implements the inode attribute propagation (or inheritance), t=
hen
> only users of cp -a are impacted.  They are more likely to be aware tha=
t
> they may be creating new files with reduced-integrity storage attribute=
s.

True, although I think this aspect of attribute-copying will typically=20
come as a surprise even to "cp -a" users.

> If the file is empty, you can chattr +C or -C.  If the file is not
> empty, chattr fails with an error.

Although coreutils 'cp -a' currently truncates any already-existing=20
output file (by opening it with O_TRUNC), it then calls copy_file_range=20
before calling fsetxattr on the destination. Presumably cp should do the=20
equivalent of chattr +C before doing the copy_file_range stuff. (Perhaps=20
you've already mentioned this point; if so, my apologies for the=20
duplication.)

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
Resent-From: Zygo Blaxell <ce3g8jdj@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 08 Jun 2021 02:55:01 +0000
Resent-Message-ID: <handler.48833.B48833.162312088111756 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 48833
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Paul Eggert <eggert@HIDDEN>
Cc: 48833 <at> debbugs.gnu.org, linux-btrfs@HIDDEN, Tom Yan <tom.ty89@HIDDEN>
Received: via spool by 48833-submit <at> debbugs.gnu.org id=B48833.162312088111756
          (code B ref 48833); Tue, 08 Jun 2021 02:55:01 +0000
Received: (at 48833) by debbugs.gnu.org; 8 Jun 2021 02:54:41 +0000
Received: from localhost ([127.0.0.1]:57161 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lqRt3-00033Y-66
	for submit <at> debbugs.gnu.org; Mon, 07 Jun 2021 22:54:41 -0400
Received: from james.kirk.hungrycats.org ([174.142.39.145]:33106)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <postmaster@HIDDEN>) id 1lqRgX-0002lc-WF
 for 48833 <at> debbugs.gnu.org; Mon, 07 Jun 2021 22:41:46 -0400
Received: by james.kirk.hungrycats.org (Postfix, from userid 1002)
 id 244ABA92DA4; Mon,  7 Jun 2021 22:41:44 -0400 (EDT)
Date: Mon, 7 Jun 2021 22:41:44 -0400
From: Zygo Blaxell <ce3g8jdj@HIDDEN>
Message-ID: <20210608024144.GB11713@HIDDEN>
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
 <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
 <20210604201630.GH11733@HIDDEN>
 <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
 <20210606054242.GI11733@HIDDEN>
 <4354c814-9f9f-0c26-fb11-36567da6f530@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4354c814-9f9f-0c26-fb11-36567da6f530@HIDDEN>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score: 0.2 (/)
X-Mailman-Approved-At: Mon, 07 Jun 2021 22:54:40 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.8 (/)

On Sun, Jun 06, 2021 at 10:47:05PM -0700, Paul Eggert wrote:
> On 6/5/21 10:42 PM, Zygo Blaxell wrote:
> > If cp -a implements the inode attribute propagation (or inheritance), then
> > only users of cp -a are impacted.  They are more likely to be aware that
> > they may be creating new files with reduced-integrity storage attributes.
> 
> True, although I think this aspect of attribute-copying will typically come
> as a surprise even to "cp -a" users.

Existing users might be surprised when "cp -a" starts replicating storage
attributes when it did not do so before, but I suspect most future cp
users would expect "cp -a" to preserve storage-policy attributes the same
way it currently preserves ownership, permissions, timestamps, extended
attributes, and security context--a list that initially contained only
the ownership, permissions, and timestamps in the past, the others were
added over time.  If not by default, then at least have the ability to
do it when requested with a "--preserve=datacow" switch.

We could say "cp --reflink=always implies --preserve=datacow because it
might not work otherwise", which solves the immediate issue as presented,
but I don't think we _want_ to say that because it has a potentially
bad surprising case when attribute changes are unexpected (it's the same
reason that we would not want to implement it that way in the kernel).
As a cp user, I would prefer to make the choice to copy the storage
attributes with --preserve or -a, and after that choice is made, then
--reflink=always will work because cp is setting attributes in dst to
match src as I requested it to do.  If I had made the opposite choice
(didn't use -a or --preserve, or did use --no-preserve=datacow), then
cp shall not copy the storage attributes, the dst inodes have attributes
inherited from dst's parent, --reflink=always fails when there are
mismatches as it does now, and --reflink=auto or =none copies may have
different storage attributes from the src (with possibly stronger or
weaker integrity).

We could say "'cp -a --reflink=always' implies --preserve=datacow, but
'--reflink=always' and '-a' by themselves do not."  It seems complex
to describe, but maybe it does surprise the fewest people in the most
beneficial way:  plain 'cp -a' users keep exactly the old behavior,
while 'cp -a --reflink=always' users get successful copies in one case
where they currently get unexpected failures.  'cp -r' doesn't imply
--preserve=all, so 'cp -r --reflink=always' would need to be accompanied
by '--preserve=datacow' or '--preserve=all' to get the attribute-copying.

The cp doc could be clearer that filesystems that support reflink
don't guarantee every file can be reflinked to every other file.
reflink is expected to fail in a growing number of cases over time,
as more filesystem features are created that are incompatible with it
(e.g. encryption, where reflinks between files with different owners could
be unimplementable).  I've seen a number of users get burned by making big
--reflink=always copies and not checking the results for errors, assuming
that only lack of space for metadata could cause a reflink copy to fail.
There are good reasons why --reflink=auto exists and is the default,
and users ignore them at their peril.

The really awful thing about all this is that it's not datacow, the
thing visible with chattr +/-C and implemented by other filesystems,
that is the problem.  The problem is the datasum bit hidden behind the
datacow bit on btrfs.  datasum can still be disabled even when datacow
is enabled, and datasum requires privileges to detect (unprivileged
users can only observe the datasum bit's effect on reflink copies to
files with the opposite datasum setting).  The proper option name should
be --preserve=datasum, but cp can only examine or change the datacow bit.

> > If the file is empty, you can chattr +C or -C.  If the file is not
> > empty, chattr fails with an error.
> 
> Although coreutils 'cp -a' currently truncates any already-existing output
> file (by opening it with O_TRUNC), it then calls copy_file_range before
> calling fsetxattr on the destination. Presumably cp should do the equivalent
> of chattr +C before doing the copy_file_range stuff. (Perhaps you've already
> mentioned this point; if so, my apologies for the duplication.)

The important thing is that got across, whether you extracted it from what
I wrote, or reconstructed it from context.

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
Resent-From: A L <mail@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Sun, 27 Jun 2021 13:09:01 +0000
Resent-Message-ID: <handler.48833.B.162479928330176 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 48833
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: 48833 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-coreutils@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.162479928330176
          (code B ref -1); Sun, 27 Jun 2021 13:09:01 +0000
Received: (at submit) by debbugs.gnu.org; 27 Jun 2021 13:08:03 +0000
Received: from localhost ([127.0.0.1]:49066 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lxUVz-0007qJ-K5
	for submit <at> debbugs.gnu.org; Sun, 27 Jun 2021 09:08:03 -0400
Received: from lists.gnu.org ([209.51.188.17]:42488)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <postmaster@HIDDEN>) id 1lxSBn-0008Ky-SV
 for submit <at> debbugs.gnu.org; Sun, 27 Jun 2021 06:39:14 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:51670)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>)
 id 1lxSBn-0004jj-L2
 for bug-coreutils@HIDDEN; Sun, 27 Jun 2021 06:38:59 -0400
Received: from ste-pvt-msa2.bahnhof.se ([213.80.101.71]:30348)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <postmaster@HIDDEN>)
 id 1lxSBh-0007r8-9P
 for bug-coreutils@HIDDEN; Sun, 27 Jun 2021 06:38:58 -0400
Received: from localhost (localhost [127.0.0.1])
 by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTP id DF4D03F65E
 for <bug-coreutils@HIDDEN>; Sun, 27 Jun 2021 12:38:47 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at bahnhof.se
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level: 
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=6.31
 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.202, URIBL_BLOCKED=0.001]
 autolearn=ham autolearn_force=no
Received: from ste-pvt-msa2.bahnhof.se ([127.0.0.1])
 by localhost (ste-ftg-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id lqY9ZH6iTW89 for <bug-coreutils@HIDDEN>;
 Sun, 27 Jun 2021 12:38:46 +0200 (CEST)
Received: by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id E24A73F59B
 for <bug-coreutils@HIDDEN>; Sun, 27 Jun 2021 12:38:46 +0200 (CEST)
Received: from [192.168.0.10] (port=64798)
 by tnonline.net with esmtpsa  (TLS1.3) tls TLS_AES_128_GCM_SHA256
 (Exim 4.94.2) (envelope-from <mail@HIDDEN>)
 id 1lxSBZ-000HrC-To
 for bug-coreutils@HIDDEN; Sun, 27 Jun 2021 12:38:46 +0200
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
 <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
 <20210604201630.GH11733@HIDDEN>
 <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
 <20210606054242.GI11733@HIDDEN>
 <4354c814-9f9f-0c26-fb11-36567da6f530@HIDDEN>
 <20210608024144.GB11713@HIDDEN>
From: A L <mail@HIDDEN>
Message-ID: <1ea0660b-f73f-4102-b7f3-8aaf02a6c0dd@HIDDEN>
Date: Sun, 27 Jun 2021 12:38:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210608024144.GB11713@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=213.80.101.71;
 envelope-from=postmaster@HIDDEN; helo=ste-pvt-msa2.bahnhof.se
X-Spam_score_int: -23
X-Spam_score: -2.4
X-Spam_bar: --
X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  On 2021-06-08 04:41, Zygo Blaxell wrote: > On Sun, Jun 06,
 2021 at 10:47:05PM -0700, Paul Eggert wrote: >> On 6/5/21 10:42 PM, Zygo
 Blaxell wrote: >>> If cp -a implements the inode attribute propagati [...]
 Content analysis details:   (1.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
 mail domains are different
 0.0 T_SPF_HELO_TEMPERROR   SPF: test of HELO record failed (temperror)
 0.9 SPF_FAIL               SPF: sender does not match SPF record (fail)
 [SPF failed: Please see http://www.openspf.org/Why?s=mfrom;
 id=postmaster%40tnonline.net; ip=209.51.188.17; r=debbugs.gnu.org]
 -0.0 NICE_REPLY_A           Looks like a legit reply (A)
X-Mailman-Approved-At: Sun, 27 Jun 2021 09:07:58 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.9 (---)


On 2021-06-08 04:41, Zygo Blaxell wrote:
> On Sun, Jun 06, 2021 at 10:47:05PM -0700, Paul Eggert wrote:
>> On 6/5/21 10:42 PM, Zygo Blaxell wrote:
>>> If cp -a implements the inode attribute propagation (or inheritance), then
>>> only users of cp -a are impacted.  They are more likely to be aware that
>>> they may be creating new files with reduced-integrity storage attributes.
>>
>> True, although I think this aspect of attribute-copying will typically come
>> as a surprise even to "cp -a" users.
> 
> Existing users might be surprised when "cp -a" starts replicating storage
> attributes when it did not do so before, but I suspect most future cp
> users would expect "cp -a" to preserve storage-policy attributes the same
> way it currently preserves ownership, permissions, timestamps, extended
> attributes, and security context--a list that initially contained only
> the ownership, permissions, and timestamps in the past, the others were
> added over time.  If not by default, then at least have the ability to
> do it when requested with a "--preserve=datacow" switch.

...

> The cp doc could be clearer that filesystems that support reflink
> don't guarantee every file can be reflinked to every other file.
> reflink is expected to fail in a growing number of cases over time,
> as more filesystem features are created that are incompatible with it
> (e.g. encryption, where reflinks between files with different owners could
> be unimplementable).  I've seen a number of users get burned by making big
> --reflink=always copies and not checking the results for errors, assuming
> that only lack of space for metadata could cause a reflink copy to fail.
> There are good reasons why --reflink=auto exists and is the default,
> and users ignore them at their peril.
> 

Hello everyone,
I made a similar thread[1] about a year ago on the coreutils 
mailing-list and I think it is also relevant to this bug-report.

It is true as Zygo mentions, that reflinking nocow and cow files does 
not work, and cannot work due to the nature of how nocow works.

What I would like to add to this bug-report is what elaborated on in the 
other thread, that we can move forward with preserving all attributes by 
setting them in the correct order. I show in the message that reflinking 
works between two nocow files and that ‘cp -a’ could preserve nocow and 
other attributes if ‘cp -a’ sets those attributes in correct order.

As a normal end-user, IMHO, ‘cp -a’ should preserve all attributes where 
possible, which is also what the manual[2] currently states:

‘--archive’
Preserve as much as possible of the structure and attributes of the 
original files in the copy (but do not attempt to preserve internal 
directory structure; i.e., ‘ls -U’ may list the entries in a copied 
directory in a different order). Try to preserve SELinux security 
context and extended attributes (xattr), but ignore any failure to do 
that and print no corresponding diagnostic. Equivalent to -dR 
--preserve=all with the reduced diagnostics.


Only when using --reflink=always, we should fail if the target cannot 
support reflinks.

Thanks!

~A


[1] https://lists.gnu.org/archive/html/coreutils/2021-06/msg00005.html that
[2] 
https://www.gnu.org/software/coreutils/manual/html_node/cp-invocation.html#cp-invocation

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
Resent-From: A L <mail@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Sun, 27 Jun 2021 13:09:02 +0000
Resent-Message-ID: <handler.48833.B48833.162479928730186 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 48833
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Zygo Blaxell <ce3g8jdj@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Cc: 48833 <at> debbugs.gnu.org, linux-btrfs@HIDDEN, Tom Yan <tom.ty89@HIDDEN>
Received: via spool by 48833-submit <at> debbugs.gnu.org id=B48833.162479928730186
          (code B ref 48833); Sun, 27 Jun 2021 13:09:02 +0000
Received: (at 48833) by debbugs.gnu.org; 27 Jun 2021 13:08:07 +0000
Received: from localhost ([127.0.0.1]:49068 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1lxUW3-0007qf-DL
	for submit <at> debbugs.gnu.org; Sun, 27 Jun 2021 09:08:07 -0400
Received: from pio-pvt-msa2.bahnhof.se ([79.136.2.41]:34982)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <postmaster@HIDDEN>) id 1lxSSm-0002UF-92
 for 48833 <at> debbugs.gnu.org; Sun, 27 Jun 2021 06:56:33 -0400
Received: from localhost (localhost [127.0.0.1])
 by pio-pvt-msa2.bahnhof.se (Postfix) with ESMTP id D22BE3F39C;
 Sun, 27 Jun 2021 12:56:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at bahnhof.se
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=6.31
 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, URIBL_BLOCKED=0.001]
 autolearn=ham autolearn_force=no
Received: from pio-pvt-msa2.bahnhof.se ([127.0.0.1])
 by localhost (pio-pvt-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Y2lkU5931y7i; Sun, 27 Jun 2021 12:56:29 +0200 (CEST)
Received: by pio-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id AD5183F319;
 Sun, 27 Jun 2021 12:56:28 +0200 (CEST)
Received: from [192.168.0.10] (port=52546)
 by tnonline.net with esmtpsa  (TLS1.3) tls TLS_AES_128_GCM_SHA256
 (Exim 4.94.2) (envelope-from <mail@HIDDEN>)
 id 1lxSSh-000IY6-Po; Sun, 27 Jun 2021 12:56:27 +0200
References: <CAGnHSEkr0N_hnxvm89prL3vObYgvVoPFHLL4Z7wnQCSem6hB_A@HIDDEN>
 <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
 <20210604201630.GH11733@HIDDEN>
 <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@HIDDEN>
 <20210606054242.GI11733@HIDDEN>
 <4354c814-9f9f-0c26-fb11-36567da6f530@HIDDEN>
 <20210608024144.GB11713@HIDDEN>
From: A L <mail@HIDDEN>
Message-ID: <14a60f28-6a74-3315-b756-56ee4b84d583@HIDDEN>
Date: Sun, 27 Jun 2021 12:56:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <20210608024144.GB11713@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.5 (/)
X-Mailman-Approved-At: Sun, 27 Jun 2021 09:07:58 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.2 (---)


On 2021-06-08 04:41, Zygo Blaxell wrote:
 > On Sun, Jun 06, 2021 at 10:47:05PM -0700, Paul Eggert wrote:
 >> On 6/5/21 10:42 PM, Zygo Blaxell wrote:
 >>> If cp -a implements the inode attribute propagation (or 
inheritance), then
 >>> only users of cp -a are impacted.  They are more likely to be aware 
that
 >>> they may be creating new files with reduced-integrity storage 
attributes.
 >>
 >> True, although I think this aspect of attribute-copying will 
typically come
 >> as a surprise even to "cp -a" users.
 >
 > Existing users might be surprised when "cp -a" starts replicating storage
 > attributes when it did not do so before, but I suspect most future cp
 > users would expect "cp -a" to preserve storage-policy attributes the same
 > way it currently preserves ownership, permissions, timestamps, extended
 > attributes, and security context--a list that initially contained only
 > the ownership, permissions, and timestamps in the past, the others were
 > added over time.  If not by default, then at least have the ability to
 > do it when requested with a "--preserve=datacow" switch.

...

 > The cp doc could be clearer that filesystems that support reflink
 > don't guarantee every file can be reflinked to every other file.
 > reflink is expected to fail in a growing number of cases over time,
 > as more filesystem features are created that are incompatible with it
 > (e.g. encryption, where reflinks between files with different owners 
could
 > be unimplementable).  I've seen a number of users get burned by 
making big
 > --reflink=always copies and not checking the results for errors, assuming
 > that only lack of space for metadata could cause a reflink copy to fail.
 > There are good reasons why --reflink=auto exists and is the default,
 > and users ignore them at their peril.
 >

Hello everyone,
I made a similar thread[1] about a year ago on the coreutils 
mailing-list and I think it is also relevant to this bug-report.

It is true as Zygo mentions, that reflinking nocow and cow files does 
not work, and cannot work due to the nature of how nocow works.

What I would like to add to this bug-report is what elaborated on in the 
other thread, that we can move forward with preserving all attributes by 
setting them in the correct order. I show in the message that reflinking 
works between two nocow files and that ‘cp -a’ could preserve nocow and 
other attributes if ‘cp -a’ sets those attributes in correct order.

As a normal end-user, IMHO, ‘cp -a’ should preserve all attributes where 
possible, which is also what the manual[2] currently states:

‘--archive’
Preserve as much as possible of the structure and attributes of the 
original files in the copy (but do not attempt to preserve internal 
directory structure; i.e., ‘ls -U’ may list the entries in a copied 
directory in a different order). Try to preserve SELinux security 
context and extended attributes (xattr), but ignore any failure to do 
that and print no corresponding diagnostic. Equivalent to -dR 
--preserve=all with the reduced diagnostics.


Only when using --reflink=always, we should fail if the target cannot 
support reflinks.

Thanks!

~A


[1] https://lists.gnu.org/archive/html/coreutils/2021-06/msg00005.html that
[2] 
https://www.gnu.org/software/coreutils/manual/html_node/cp-invocation.html#cp-invocation

Message sent to bug-coreutils@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#48833: =?UTF-8?Q?B=C4=B1rthday?= Gift
In-Reply-To: <CAGnHSEkeu1hW-7YQO0HrYK__aY-eMdxfgSbcOTvnMu3jUcu4iw@HIDDEN>
Resent-From: Leslie S Satenstein <lsatenstein@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Wed, 28 Sep 2022 13:37:02 +0000
Resent-Message-ID: <handler.48833.B48833.166437216814785 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 48833
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
Reply-To: Leslie S Satenstein <lsatenstein@HIDDEN>
Received: via spool by 48833-submit <at> debbugs.gnu.org id=B48833.166437216814785
          (code B ref 48833); Wed, 28 Sep 2022 13:37:02 +0000
Received: (at 48833) by debbugs.gnu.org; 28 Sep 2022 13:36:08 +0000
Received: from localhost ([127.0.0.1]:60710 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1odXEO-0003qP-6q
	for submit <at> debbugs.gnu.org; Wed, 28 Sep 2022 09:36:08 -0400
Received: from sonic322-37.consmr.mail.ne1.yahoo.com ([66.163.189.60]:42046)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <lsatenstein@HIDDEN>) id 1odXEK-0003pG-Fk
 for 48833 <at> debbugs.gnu.org; Wed, 28 Sep 2022 09:36:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1664372158; bh=ZnLfzEQ/pTwcjZ2SutFe4uZjLDl0ENQdnzge3ab4q1c=;
 h=Date:From:Reply-To:Subject:References:From:Subject:Reply-To;
 b=Q848WSLSRMLrSw0PKRhuDNt6Q1upCmpgmT0NquzubmSCGTFwQfdO1PPA0ZFjCGSZ8197uC0nPSfPJMQRV3SKPzCprEODhunZTROQmZefGU/sqG1iF5AwpZLA0a1MFPrC9i6vzbU0/ngCXDjX5OH/opIvt65jF3n7Gn/4MZZqrfiqxYyN0X9rxZcSYPrJH7hQs/qcVdSutoE2PtbAD3Zp0cNBEGY3Wa/t3+vtxq1VtuHhImZLR17Enn6UG+YGecaFOD8qrFsIfiunt+ov1axvPo4YmB/VVL/2CrV1RPTfLEd3zUv0fpU6uxSrzeLEe48ChaNwyUaUKQsRxN7bcrATdg==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1664372158; bh=CX0af7D0a63lrpfHnlY0VUsjXQfCKp4HwWglIqLMmXp=;
 h=X-Sonic-MF:Date:From:Subject:From:Subject;
 b=gTDP4ED6S28n357vXInmaP81UkYE1dT7w4ZYIGVgNNTXWkf81uc5B42jO0UJv+0i2O740ucH8+YGe0SDjsEu8L46wxLU+GeZK2TxJ1o/wkaI/2w/dz66R50b6LS5QupJcZci0ZqllTHtHUimrmbWwzcNOl+go5eJCVJc/Hw+FaD71wX9H5XKbVdi66kwRyG78rmgSLdqdi94fJDcZLyEX34lGXmTvYKOf9MsNeMrEpzRYw+CsadQbu8qJC1XM/Tqr2nc7qnyws34aQlaRs/+Y2gECFEZw+4sh2r/7pS4YICelWkQqqfKwvbjalnuW8unLc7CHZtpXNh4CfoHxM1DJA==
X-YMail-OSG: Etz8NnwVM1kk.2qB5TxaGu.lrFZIIQy2JBQvJRGBvnxYgom8VtE4Ke8V3MYzfwu
 nCrg.tmKbgfheOD.nBJaERFuZJft4yoC2ZddoXi3frKh.QryIjN_55PUx.v1Gwnx1PKLoBB.LAZT
 35b8bAHSP5Iiu8cpSAUaE00ydi7O3RcufIEuUKd1waDWlnJ5rYVEShDg2PxsfoOllaNZsmYKiPFY
 Vr_1plT9AmzFsAipgHcJJp_prO1UTCVxOGLtezSs.JvS_vYRy0KEoNub9eMp1HmVeZCVKkBIGMbE
 xISZULTvHmlVE3H443pCo564WfJy42ix7dV1elerj_ZDY1tiMVmo2fai2ihjp1bF.mpFJzQXtFO7
 tayGLrtfAKUOVNPCQJ7e1TcYi6m2c4GgMv9vRaKBd6esArS82Tb6AJpsgcmlOtfqzZp0eWhM8i9R
 OTNc5vGghvUUhcNDHFC.lSjArWKWbXNjcDOm6O.H3pWUhKhUXcm.SYrSH73ByfuPDYcOnRHpDJ3M
 mKzQ0xt7RhxDbCMl02dkR8Acfh9aZ0rt4p.gtz.fBs4pA3MYueQvKpzktV8sj79dD60MmMyFKq1x
 T2fcuXTDDIIA3FfvzqE4YedY3x0PFFZcs03PgbG7bO1131AY2FBXl7PksrFDqYJjNxQv3ueyDRfq
 wtHuz8S.rlsCabesxgYELgR0htUK3ODIzHQ952IUuMWXcYnSQ9hhAZFvQBPtxV0gfkSLxugtE_qP
 A.CANBUPj0Su2CFRolG3pnSqLeggqYkTVwur1N5YrYr0X.a6KBxC3I5LRlwiF95._RdKjAWxV0u8
 vFXUcv2oIZczC0jgZyBGvLlQo97zReOg08lm_0HuHZAZVNeUhwf0z6xRnV3DJZMbpXXbmWXJifnO
 QtgIiI30hXv2ACngDIkT4Qs7UzxBODoamR2dCOvx26sdJe7Ku5FYjW_K3ZMKF8JBbW0wH8KL.v36
 DsxQ8yLpZtX5D8z7JgWa9AYaDcfxSrY9oP4wcjBeZvQQIeCpPq19CY4xbByhCC3uP.l4OU_QYbtJ
 nJW3MDMB.tiHKlQDW8tz8PiOE1wqNRzjpZDLCK1bKbfXyzhciiKId3sgNk_HJ8xecUTobyvx4ryS
 9.6Vef3mAILpGV.UMr3yAkO65WHpqVE6kj9FyDmDrFnn2mPy.P8S9v0Iw2fENto6PQdORS4G8OST
 2lOCo1XY7wBm9i09SQ.X1RbI15Ps9rHNmLZaXBbkYRXRTp2wd1g1LNilmPZShHC4QoRI0eOwzLsT
 yLabb.XiT3AOgwvEzev7ETzDZz82fiR0O1frwJE2Zsw4ZPoSdunszVMnldIIFt1zeKlEmeBABfn4
 aejpRvcVk.xqk61kGEIZOFDpEbfP_r910T3DAwI2qziVSyWVbRrL1p13OjwgH_CmCmcO8Hubd1Xe
 .aaF1HrZ_hdDeSObtCW5W.T.Vie78zScsQCXFlwSfQurHsukQHpjMtKUqaW5VzZ6WeIL4JeDyuus
 JKqZ9luH4rP2bZapsC3mE8.VR0FDvwU70kRilANigT8Kf6hfH2i7PvD16b8czzKz2f3H6b561ohp
 AsFbZOMvH8bt44h.jihwB.Aw66XsSo2X2ZBQdt_P.sEk9I2KPhEmEwBs.SsW0oMX6jXK5vXbA7IZ
 Nluw3n5LUh_veEyyF.YmSX5Ifv.grhq85xaVHz.GM.7RjUKmZIjObK6.QFz4TbZDODwtJEEmggEH
 3jGiHg1yw8xcsmzR2lxNg0gvfrCIq6pYtgNXtOP0o1iHIjRvnTVvqVAnrWnFlWTr8kAOOWy_6axu
 31b1GCaxNtCqXRwKyexuAu.76AyqByHc3H1LKxv_ZLD3CVxem3IjG8lvWwdMTBz3YLK1XKiPPpws
 nYY7EyIbofKfqahR2o9XeAMfeYCwN6g7axHI8RMeuOQERVmvm0GB4nJPvNxLtx27JlAYKmbdNNOZ
 mhK6ja1YX.QhKJIqQJCF5xK0f9OQw_pU999rYO95PtKxI7yBQHkWXMSf5KDj6a9WeIBS0kjnLtFt
 9Klmf7xbYwFTXmciI_CwJFPjgqfmTSpESkqPPXatr8iI3FshYvrgBFcmj49gFLBPc.xQ7gGQd8v8
 4gaKhhIUmWO5n3b3IMGQSvkfk1ongKNyR9teIsIQ.N591W0Ia1yJOOuF_QXX6CNkmDstoYEderZP
 PELOZbOM.lfOC8mh5aNY92eBME4ZbnEeLUUj7aOa1S1in3Kmcu7CIsdAS0twRlMkDbL7uje6Awqq
 .x5t3Qg5KDZtu9qZ_Nns6tn0fUBVAt86o9fbX1.XD2Frcxtbn8HfaIGIYZkk9
X-Sonic-MF: <lsatenstein@HIDDEN>
Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic322.consmr.mail.ne1.yahoo.com with HTTP; Wed, 28 Sep 2022 13:35:58 +0000
Date: Wed, 28 Sep 2022 13:32:50 +0000 (UTC)
From: Leslie S Satenstein <lsatenstein@HIDDEN>
Message-ID: <1442055630.1820916.1664371970607@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_1820915_2041125903.1664371970605"
References: <1442055630.1820916.1664371970607.ref@HIDDEN>
X-Mailer: WebService/1.1.20702 YMailNorrin
Content-Length: 1889
X-Spam-Score: 4.2 (++++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hi hope you are safe and =?UTF-8?Q?good.=C2=A0I?= want to ask for a discrete
    assistance, do you order gifts and items on Amazon? =?UTF-8?Q?Regards=C2=A0Leslie?= Leslie
    Satenstein =?UTF-8?Q?Montr=C3=A9al_?= =?UTF-8?Q?Qu=C3=A9bec,?= Canada Hi hope you are safe and good. 
 
 Content analysis details:   (4.2 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [66.163.189.60 listed in list.dnswl.org]
  1.2 MISSING_HEADERS        Missing To: header
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (lsatenstein[at]yahoo.com)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.0 HTML_MESSAGE           BODY: HTML included in message
  1.9 REPLYTO_WITHOUT_TO_CC  No description available.
  1.0 FREEMAIL_REPLYTO       Reply-To/From or Reply-To/body contain
                             different freemails
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hi hope you are safe and =?UTF-8?Q?good.=C2=A0I?= want to ask for a discrete
    assistance, do you order gifts and items on Amazon? =?UTF-8?Q?Regards=C2=A0Leslie?= Leslie
    Satenstein =?UTF-8?Q?Montr=C3=A9al_?= =?UTF-8?Q?Qu=C3=A9bec,?= Canada Hi hope you are safe and good. 
 
 Content analysis details:   (2.2 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [66.163.189.60 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  1.2 MISSING_HEADERS        Missing To: header
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (lsatenstein[at]yahoo.com)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.0 HTML_MESSAGE           BODY: HTML included in message
  1.9 REPLYTO_WITHOUT_TO_CC  No description available.
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

------=_Part_1820915_2041125903.1664371970605
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 Hi hope you are safe and good.=C2=A0I want to ask for a discrete assistanc=
e, do you order gifts and items on Amazon?

Regards=C2=A0Leslie
Leslie Satenstein
Montr=C3=A9al Qu=C3=A9bec, Canada


------=_Part_1820915_2041125903.1664371970605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div class=3D"ydp8dd6d64yahoo-style-wrap" style=3D=
"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;">=
<div><div dir=3D"ltr" data-setdir=3D"false"> <div><div dir=3D"ltr" data-set=
dir=3D"false" style=3D"color: rgb(0, 0, 0); font-family: Helvetica Neue, He=
lvetica, Arial, sans-serif;">Hi hope you are safe and good.&nbsp;</div><div=
 dir=3D"ltr" data-setdir=3D"false" style=3D"color: rgb(0, 0, 0); font-famil=
y: Helvetica Neue, Helvetica, Arial, sans-serif;">I want to ask for a discr=
ete assistance, do you order gifts and items on Amazon?<br></div><div style=
=3D"color: rgb(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, san=
s-serif;"><br></div><div class=3D"ydpd5871e25signature" style=3D"color: rgb=
(0, 0, 0); font-family: Helvetica Neue, Helvetica, Arial, sans-serif;"><div=
 dir=3D"ltr" style=3D"font-family: Helvetica, Arial, sans-serif;"><span lan=
g=3D"FR-CA">Regards</span><div><b><font size=3D"2">&nbsp;Leslie</font><br><=
/b></div><div><font color=3D"green"><b><font size=3D"1">Leslie Satenstein</=
font></b></font><font size=3D"1" style=3D"color: rgb(191, 0, 95);"><span st=
yle=3D"font-weight: bold;"></span></font><br></div><font color=3D"green"><b=
>Montr=C3=A9al Qu=C3=A9bec, Canada</b></font></div><div><font color=3D"gree=
n"><b><br></b></font></div></div></div><br></div></div></div></body></html>
------=_Part_1820915_2041125903.1664371970605--

Last modified: Wed, 28 Sep 2022 13:45:01 UTC

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