* Konstantin Kharlamov: > FWIW, I was just thinking about it, and I came up with example you > may like which shows exactly why BTRFS is bad for HDD. Consider > development process. It includes rewriting source files over and > over: you do `git checkout foo` and files are overwritten, you > change a file in text editor, and it gets overwritten. And since > BTRFS is CoW, it will always write files to a new place. Editors that make a backup copy typically do not overwrite files in place. They rename the file to the backup location and then write the new file. git checkout unlinks changed files first, before writing them anew from scratch. A COW file system does not make a difference for these use cases because there is already COW at the application level. The GNU assembler truncates the output object file first. On XFS, that triggers relocation to a new file system location as well, even if the output file size (or contents) does not change. So that scenario is essentially COW as well today. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
