On 2016-06-10 13:22, Adam Borowski wrote:
On Fri, Jun 10, 2016 at 01:12:42PM -0400, Austin S. Hemmelgarn wrote:
On 2016-06-10 12:50, Adam Borowski wrote:
And, as of coreutils 8.25, the default is no reflink, with "never" not being
recognized even as a way to avoid an alias. As far as I remember, this
applies to every past version with support for reflinks too.
Odd, I could have sworn that was an option...
And I do know there was talk at least at one point of adding it and
switching to reflink=auto by default.
Yes please!
It's hard to come with a good reason for not reflinking when it's possible
-- the only one I see is if you have a nocow VM and want to slightly improve
speed at a cost of lots of disk space. And even then, there's cat a >b for
that.
There are other arguments, the most common one being not changing user
visible behavior. There are (misguided) people who expect copying a
file to mean you have two distinct copies of that file.
OTOH, it's not too hard to set up a system to do this, you just put:
alias cp='cp --reflink=auto'
into your bashrc (or something similar into whatever other shell you
use). I've been doing this since cp added support for it.
And the cost on non-btrfs non-unmerged-xfs is a single syscall per file,
that's utterly negligible compared to actually copying the data.
Actually, IIRC, it's an ioctl, not a syscall, which can be kind of
expensive (I don't know how much more expensive, but ioctls are usually
more expensive than syscalls).
Other things to keep in mind though that may impact this (either way):
1. There are other filesystems that support reflinks (OCFS2 and ZFS come
immediately to mind).
2. Most of the filesystems that support reflinks are used more in
enterprise situations, where the bit about not changing user visible
behavior is a much stronger argument.
3. Even in enterprise situations, reflink capable filesystems are still
unusual outside of petabyte scale data storage.
4. Last I checked, the most widely used filesystem that supports
reflinks (ZFS) uses a different ioctl interface for them than most other
Linux filesystems, which means more checking is needed than just calling
one ioctl.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
