[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] cp: use reflink=auto mode by default
From: |
Alexandru Moise |
Subject: |
Re: [PATCH] cp: use reflink=auto mode by default |
Date: |
Mon, 27 Jun 2016 00:18:13 +0300 |
User-agent: |
Mutt/1.6.1 (2016-04-27) |
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