On Sat, Nov 02, 2019 at 07:36:24PM +0500, Roman Mamedov wrote:
> On Sat, 2 Nov 2019 08:49:37 -0500
> Brian Hansen <dulanic@gmail.com> wrote:
> 
> > Hello,
> > 
> > First time i've sent to this group but I am trying to figure out the
> > cause of this. Normal copy is working fine, but then if I use
> > --reflink it says invalid argument. Not sure how to read some of this,
> > but here is the strace.
> > 
> > I'm running kernel v4.15
> > 
> > Here is the full output of strace. I ran a strace on normal copy and
> > most looks similar so I'm not able to figure out much here...
> > 
> > https://pastebin.com/raw/YmQ8FvCH
> 
> At first I was going to say, "oh it's because you are using 'chattr +C', or
> mounted the filesystem as nocow, and reflink copying is prevented by those".
> In fact this article from 2014 confirms that to be the case:
> http://infotinks.com/btrfs-nodatacow-reflink-copies-snapshots/
> 
> But then I tested on my machine, and what used to fail, now works:
> 
>   # mkdir tmp
>   # chattr +C tmp
>   # echo abc > tmp/a
>   # cp -a --reflink=always tmp/a tmp/b
>   # lsattr tmp/
>   ----------------C-- tmp/a
>   ----------------C-- tmp/b
> 
> According to strace, the clone IOCTL succeeds:
> 
> ...
>   openat(AT_FDCWD, "tmp/b", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4
>   fstat(4, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
>   ioctl(4, BTRFS_IOC_CLONE or FICLONE, 3) = 0
> ...
> 
> Same on kernels 4.14.151, 4.14.113 and 4.9.189.
> 
> So I wonder, is setting nocow via 'chattr +C' getting ignored now, or is there
> an improvement that it no longer prevents reflink copying?

reflink copies of nodatacow files should be OK.  'nodatacow' just means
'don't COW *unshared* extents in this file'.  If an extent is shared
by clone, dedupe, or snapshot then it is COW until only one reference
remains.

> -- 
> With respect,
> Roman