From: Forza <forza@tnonline.net>
To: Tom Yan <tom.ty89@gmail.com>,
Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Cc: linux-btrfs@vger.kernel.org, bug-coreutils@gnu.org
Subject: Re: reflink copying does not check/set No_COW attribute and fail
Date: Sat, 5 Jun 2021 12:35:45 +0200 [thread overview]
Message-ID: <56d734d0-d0f6-4d64-7b6f-9ea8ad2858d4@tnonline.net> (raw)
In-Reply-To: <CAGnHSEk-+2tA21+sN4dioYbs_u4m_NiLPkG8u6ONJS=JbCACoA@mail.gmail.com>
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
next prev parent reply other threads:[~2021-06-05 10:35 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 [this message]
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
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=56d734d0-d0f6-4d64-7b6f-9ea8ad2858d4@tnonline.net \
--to=forza@tnonline.net \
--cc=bug-coreutils@gnu.org \
--cc=ce3g8jdj@umail.furryterror.org \
--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.