[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