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
