On Thu, Jul 21, 2016 at 6:46 AM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote: > On 2016-07-20 15:58, Chris Murphy wrote: >> >> On Sun, Jul 17, 2016 at 3:08 AM, Hendrik Friedel <hend...@friedels.name> >> wrote: >> >>> Well, btrfs does write data very different to many other file systems. On >>> every write the file is copied to another place, even if just one bit is >>> changed. That's special and I am wondering whether that could cause >>> problems. >> >> >> It depends on the application. In practice, the program most >> responsible for writing the file often does a faux-COW by writing a >> whole new (temporary) file somewhere, when that operation completes, >> it then deletes the original, and move+renames the temporary one into >> place where the original one, doing fsync in between each of those >> operations. I think some of this is done via VFS also. It's all much >> more metadata centric than what Btrfs would do on its own. > > I'm pretty certain that the VFS itself does not do replace by rename type > stuff.
I can't tell what does it. But so far every program I've tried: vi, gedit, GIMP, writes out a new file - as in, it has a different inode number and every extent has a different address. That every program reimplements this faux-COW would kinda surprise me rather than just letting the VFS do it for everyone. I think since ancient times literally overwriting files is just a bad idea that pretty much guarantees data loss of old and new data if something interrupts that overwrite. >BTRFS by nature technically does though, it's the same idea as a COW > update, just at a higher level, so we're technically doing the same thing > for every single block that changes. The only issue I can think of in this > context with a replace by rename is that you end up hitting the metadata > trees twice. Do programs have a way to communicate what portion of a data file is modified, so that only changed blocks are COW'd? When I change a single pixel in a 400MiB image and do a save (to overwrite the original file), it takes just as long to overwrite as to write it out as a new file. It'd be neat if that could be optimized but I don't see it being the case at the moment. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
