On Thu, 2020-07-02 at 09:44 +0200, Florian Weimer wrote: > * 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. Per my understanding what happens when you write a new file and delete an old one is that a block that old file was taking gets freed. Then, if you copy the file again, file system should find a free block to write this copy into. And this block likely would be the one that got freed previously. So, well, it is indeed COW, but not the one BTRFS does. It's a COW that copies a file back and forth between two blocks :) This is kinda HDD-friendly COW :) BTRFS on the other hand will not rewrite older block unless it's out of new ones. _______________________________________________ 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
