GNU bug report logs -
#48833
reflink copying does not check/set No_COW attribute and fail
Previous Next
Full log
Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 2 years and 263 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.