cp --reflink=auto by default

[Pádraig Brady]

On 20/05/15 11:48, Lennart Poettering wrote:
> On Tue, 19.05.15 02:33, Pádraig Brady (address@hidden) wrote:
> 
>> FYI...
>>
>> mv reflinks by default, but only in the unreleased V8.24 (Fedora 23).
>>
>> cp doesn't default to --reflink=auto as that would break the case where one 
>> uses copy
>> for durability reasons to have a second copy of the data.  Also for 
>> performance reasons
>> you may want the writes to happen at copy time rather than some latency 
>> sensitive process
>> working on a CoW file and being delayed by the writes possibly to a 
>> different part of a mechanical disk.
> 
> I am pretty sure that both those usecases are of the more exotic kind,
> and that reflinks should hence be the default, and people who want the
> byte-by-byte kind of copy should request it explicitly with
> --reflink=no or dd.
> 
> I think a good user interface make the common operations easy (and
> hence default) and the exotic ones possible.

Well I certainly agree on that generic point:
http://www.pixelbeat.org/docs/power_of_the_default.html

> For me that clearly means
> that --reflink=auto should be the default, and --reflink=no the
> option, and *not* the other way round...

This is something we may consider changing in coreutils >= 9.
Especially considering data deduplication is being added
to more and lower layers, which makes the first point
about implicit bit duplication less valid.
The performance concern is still valid, though again less so with SSDs.

Another thing I didn't mention was consistency with different file systems.
Currently we call a BTRFS specific ioctl to do the reflink().
It would be much better that a reflink vfs/syscall was available,
before we enabled this by default.
I see reflink is being actively worked on in XFS for example
and might be available in kernel 4.3 or 4.4 (6 months or so).
A corresponding reflink() syscall would make a lot of sense
along with that effort.

thanks,
Pádraig.