On Wed, 20.05.15 12:41, Pádraig Brady (p...@draigbrady.com) wrote: > On 20/05/15 11:48, Lennart Poettering wrote: > > On Tue, 19.05.15 02:33, Pádraig Brady (p...@draigbrady.com) 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel