Re: [PATCH] cp: use reflink=auto mode by default

[Alexandru Moise]

On Sun, Jun 26, 2016 at 07:23:02PM +0100, Pádraig Brady wrote:
> On 26/06/16 18:07, Alexandru Moise wrote:
> > On some filesystems (BTRFS), copying a file within the filesystem may
> > cross subvolume boundaries and we can use a lightweight reflink copy,
> > which is faster than a full file copy.
> 
> Note the above is accurate for mv, but for cp it's significant
> for _any_ copy within a BTRFS file system.

To be fair it's also accurate for _any_ move within a BTRFS file system :)
Also you actually not might always want this for moves. And non-CoW copies 
should
always be optional, while CoW copies being default. Consider the following:

Say we have a small 1G filesystem:

# btrfs sub create a
# btrfs sub create b
# btrfs prop set b compression zlib
# mkdir b/dir
# dd if=/dev/zero of=a/file bs=1M count=200

Disk usage should now be 200M in this filesystem
# mv a/file b/
Due to mv reflinking, the file is still 200M, no compression takes place.
And if we move it around the same subvolume:
# mv b/file b/dir
Disk usage is still 200M

If I want that file to be compressed I have to copy it turning off CoW 
explicitly. That can
only be achieved with the present behavior of cp binary. This patch was just a 
proposal and
it DOES break certain use cases as was previously shown.

Strangely files with chattr +C still get CoW-ed. That is why I'm also 
suggesting a
cp --reflink=never option for when we want explicitly to noCoW-copy files, and 
mv should
have such an option as well. If we go in that direction I will also send 
patches implementing
these options as well. _IF_ we go this way.

> 
> > This is enabled by default because it's only an optimization for
> > the fall back copy and does not break user expectations or usability.
> 
> That simplifies the argument a bit, but I think there is some weight behind 
> this change.
> Coincidentally? I commented recently at 
> https://news.ycombinator.com/item?id=11937781
> where I describe there why cp may want to change this default behavior.
> However I allude there to an implementation using copy_file_range() to be more
> file system agnostic rather than trying something BTRFS specific
> and falling back each time.
> 
> thanks,
> Pádraig

Hm, yes I agree with you that this sort of change should ultimately be done at 
the VFS layer
I intend to investigate in the future as to how this should be implemented.
I don't see it being that problematic that we "fall back each time" however, 
there's no
noticeable overhead, this kind of change could probably be only noticeable in a 
micro-brenchmark :)
src/install.c should probably remain as it is regarding reflink mode, I can 
imagine it would
cause some issues to a lot of build systems.
I will take a few days to reflect on this change and do some research in this 
area.

Thank you very much for your reply, if you have further thoughts on this I 
would love to hear them.

Thanks,
        Alex