[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#48833: reflink copying does not check/set No_COW attribute and fail

From: A L
Subject: bug#48833: reflink copying does not check/set No_COW attribute and fail
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

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:

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.



[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]