coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cp --reflink=auto by default


From: Lennart Poettering
Subject: Re: cp --reflink=auto by default
Date: Wed, 20 May 2015 14:25:37 +0200

On Wed, 20.05.15 12:41, Pádraig Brady (address@hidden) wrote:

> 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.

Well, sure, but it's a balance. It might make the later access a bit
slower due to fragmentation, but cp itself would become a *ton* faster...

Lennart

-- 
Lennart Poettering, Red Hat



reply via email to

[Prev in Thread] Current Thread [Next in Thread]