Arch Linux

nehek

Member

Registered: 2025-04-06

Posts: 2

[SOLVED] Are file copies or unique on copy-on-write (COW) filesystems?

I can't find anyone spelling out the answer.
EXT4 does what I'd expect. If I copy 1GB file 20 times then I'll have 20 new files consuming 20GB. New inodes, metadata. If I don't want that, hardlinks and symlinks exist.

BTRFS seems like it isn't a copy-on-write filesystem, its "copy-on-modify." Until the copied file is modified, it still points to the original file. This can't be disabled without using nodatacow, which also disables every cool feature.
ZFS is what I'm considering instead. But the same question arises here. At this point, I figure I'd just ask for clarification.

But is this really the case If it is, can I disable it on either filesystem? So if I copy files, they are truly unique, new, independant even if they are unmodified. No, usingcp --reflink doesn't count.
I don't want to add that every time. Nor for rsync. Nor check how every GUI and wine app does it to know they do it too. Nor set up aliases to ensure they do. Just looking for an upgrade to EXT4 (compression, etc) if it behaves the same.

I've read the wiki pages, but if the answer is there then it didn't click.
Thanks!

Last edited by nehek (2025-04-06 23:55:15)

GMP

Member

Registered: 2014-02-26

Posts: 31

Re: [SOLVED] Are file copies or unique on copy-on-write (COW) filesystems?

But is this really the case? If it is, can I disable it on either filesystem? So if I copy files, they are truly unique, new, independent even if they are unmodified. No, using `cp --reflink` doesn't count.

Short Answer:
Yes, you can force independent copies (see below), but this undermines BTRFS/ZFS's design. Unless you have a specific issue (e.g., database corruption, app crashes), it’s better to adapt to CoW—it’s how these filesystems deliver their core features (snapshots, checksums, etc.).

1. The Pragmatic Arch Approach
Arch is about choice, but also efficiency. If you’re disabling CoW globally, ask:

• Is there a measurable problem? (e.g., "SQLite fails with CoW")

• Can you target the exception? (e.g., use

  chattr +C /path/to/file

  on just the problematic files)

• Would EXT4/XFS actually solve it? (CoW isn’t "wrong"—it’s a trade-off)

2. How to Disable CoW (If You Must)

• BTRFS:

  • Temporary:

    cp --reflink=never file1 file2

  • Per-file/dir:

    chattr +C /path/to/file

    (must be empty)

  • Nuclear:

    mount -o nodatacow

    (disables checksums/compression!)

• ZFS:

  • Temporary:

    cp --reflink=never

  • Global (if supported):

    ZFS_NO_REFLINK=1

3. When to Consider EXT4/XFS
If you:

• Don’t use snapshots/compression,

• Have a proven performance hit (e.g., benchmarks showing CoW overhead),

• Prefer simplicity over features,

then EXT4/XFS (

mkfs.xfs -m reflink=0

) may be better. But document why—others can learn from your case.

References:
- BTRFS CoW
- ZFS Block Cloning

Note: Arch favors solutions over philosophy. If you have a specific issue (e.g., "Wine app X breaks with CoW"), share details—we can help better.

---

Simplicity is the ultimate sophistication.

nehek

Member

Registered: 2025-04-06

Posts: 2

Re: [SOLVED] Are file copies or unique on copy-on-write (COW) filesystems?

That's a really good answer! Thanks!

ZFS with ZFS_NO_REFLINK=1 seems to be what I want, a COW filesystem with typical storage. I'll test on, on my own to see if it's a good fit.
BTRFS without COW seems like EXT4 without journaling. Nodatacow makes most sense for large directories (VMs storage), not the entire filesystem.

But document why—others can learn from your case.

I envisioned COW primarily as the journaling replacement, simply. Copy file, don't overwrite but write new file elsewhere, free old file blocks. While any interruption leaves the original file safe until it's replaced.
COW filesystems accompanied by mandatory reflinks, deduplications isn't that. Like nodatacow existing optionally, reflinks/etc should be that too. Maybe a mount option, or like ZFS_NO_REFLINK.
I'm a very space-conscious. My files are organized, with only some few symlinks. I have no need for hardlinks; so in essence, I have no need for COW behaving this way.
Independant copies do not undermining the design, many of the advanced features will still be available after all. This.. may be someone's solution, but it solves nothing for me.