The Linux "copy problem"

Posted Jun 16, 2019 17:40 UTC (Sun) by nevyn (guest, #33129)
In reply to: The Linux "copy problem" by jezuch
Parent article: The Linux "copy problem"

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.