From: A L <mail@lechevalier.se>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
Paul Eggert <eggert@cs.ucla.edu>
Cc: 48833@debbugs.gnu.org, linux-btrfs@vger.kernel.org,
Tom Yan <tom.ty89@gmail.com>
Subject: Re: bug#48833: reflink copying does not check/set No_COW attribute and fail
Date: Sun, 27 Jun 2021 12:56:28 +0200 [thread overview]
Message-ID: <14a60f28-6a74-3315-b756-56ee4b84d583@lechevalier.se> (raw)
In-Reply-To: <20210608024144.GB11713@hungrycats.org>
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
prev parent reply other threads:[~2021-06-27 10:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-04 14:33 reflink copying does not check/set No_COW attribute and fail Tom Yan
2021-06-04 14:37 ` Tom Yan
2021-06-04 20:16 ` Zygo Blaxell
2021-06-05 5:56 ` Tom Yan
2021-06-05 10:35 ` Forza
2021-06-06 5:42 ` Zygo Blaxell
2021-06-07 5:47 ` bug#48833: " Paul Eggert
2021-06-08 2:41 ` Zygo Blaxell
2021-06-27 10:56 ` A L [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14a60f28-6a74-3315-b756-56ee4b84d583@lechevalier.se \
--to=mail@lechevalier.se \
--cc=48833@debbugs.gnu.org \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=eggert@cs.ucla.edu \
--cc=linux-btrfs@vger.kernel.org \
--cc=tom.ty89@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.