[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:56:28 +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]