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