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@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
