bug#48833: reflink copying does not check/set No_COW attribute and fail

[Forza]

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