On Thu, Oct 23, 2025, at 5:49 PM, home user wrote:
> I have no real use for either feature. They add complexity and risk, > and slow things down. Instead of overwriting, COW redirects those writes to unused space. There aren't extra writes. Also, nodatacow doesn't disable metadatacow which is still always on and can't be turned off. Same thing, instead of overwriting, the same writes are placed in free space. And only once committed to stable media are zero ref extents freed for reuse. Whatever extra writes there are for metadata comes in the case where a 16 KiB metadata block has only a few bytes of change and instead of overwriting a 512 byte or 4096 byte physical sector, the entire 16 KiB block is read, modified, and written somewhere else. There is some write amplification here but hence rather significantly delayed allocation which permits many such small modifications to be aggregated such that it mostly doesn't matter in the real world to performance. > I do not anticipate space issues for years, if ever. > I have already experienced sluggishness, even delay, which seems most > likely due to one or both of these features. Both features are used at Meta, with millions of instances in their data centers. Millions. They use it to save money by reducing write wear. > I can easily imagine these features causing me problems in the future, > though rarely. > There are some private things involved. > > Checksums - If I understand that concept correctly, I would like to have > that. But for me, it is a nice-to-have, not something that I need. I > don't like that checksums are tied to COW, and I don't see why btrfs > engineers had to tie those together. If you allow data to be overwritten there is a period of time during which the data csums are either wrong or have to be marked as not valid until later updated. Whereas with COW, all of these changes can happen in an atomic manner and thus crash safe. >> You can add "chattr +C" to all directories, perhaps someone more clever than >> I am, can come up with a find command to look for directories and execute a >> chattr +C on them. New files will then inherit nodatacow thus nodatasum and >> no compression. It's not exactly something I'd advise though. > That I already did. "/home" has only one sub-directory (so far) - the > admin's (not root's) home. (I sure wish root's home was also under > "/home": "/home/root".) > > So turning off COW also turns off compression? Correct. It only applies to new files. Existing files continue to be COW and compressed. >> How did you do this? > Just as the referenced web pages said: the "mv" command, the "mkdir" > command, the "chattr" command, and the "cp" command. OK yeah if you set nodatacow on new/ and then cp -a old/* new/ then that will force a rewrite of all the data extents, i.e. instead of default reflink=always you end up getting reflink=never behavior in this case. So I think it will do what you want. You can confirm with the compsize command. -- Chris Murphy -- _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
