The Linux "copy problem"

Posted May 30, 2019 10:35 UTC (Thu) by jezuch (subscriber, #52988)
Parent article: The Linux "copy problem"

I don't cp often but when I do I cp --reflink

to post comments

The Linux "copy problem"

Posted May 31, 2019 9:33 UTC (Fri) by LtWorf (subscriber, #124958) [Link] (2 responses)

Some of us don't use experimental filesystems.

The Linux "copy problem"

Posted May 31, 2019 14:44 UTC (Fri) by jhoblitt (subscriber, #77733) [Link] (1 responses)

Doesn't XFS has reflink() support?

The Linux "copy problem"

Posted May 31, 2019 15:46 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

Yes. Enabled by default in recent Fedora and RHEL 8 as well.

The Linux "copy problem"

Posted Jun 16, 2019 17:40 UTC (Sun) by nevyn (guest, #33129) [Link] (2 responses)

Why is this not the default?

The Linux "copy problem"

Posted Jun 20, 2019 6:51 UTC (Thu) by jezuch (subscriber, #52988) [Link] (1 responses)

I think people were concerned with loss of redundancy. Some claimed that they make a copy because they want to *really* have an actual copy and making it COW by default is surprising to the user by basically changing the contract of the command.

That's how I remember it at least.

Anyway, when I copy something it's mostly because I screwed up and I am restoring things from a btrfs backup snapshot. Making a real copy would cause unnecessary duplication in the backup - and would be unnecessarily slow and drive-thrashing. But that's just my use case.

The Linux "copy problem"

Posted Jun 24, 2019 14:28 UTC (Mon) by nix (subscriber, #2304) [Link]

Reflinking does, inevitably, reduce the fragmentation-resistance of the filesystem if you use it a lot and tend to keep the post-reflinked files for longer than the pre-reflinked ones. (That's the whole point, after all: the new blocks are necessarily going to be fragmented wrt the old ones, even if this is reduced by writing more than strictly needed in the CoW phase.)

Ideally, a background preen phase would rewrite such things after a while so they are non-fragmented again. I guess one could call xfs_fsr from cron to do that... on an SSD this matters not at all, of course, and not very much if there's a caching layer like LVM's or bcache in the way either. But it's a real concern on unintermediated spinning rust.