Hugo Mills posted on Thu, 17 Sep 2015 19:43:14 +0000 as excerpted: >> Is nodatacowbutkeepdatachecksums a feature that might turn up >> in the future? > > No. If you try doing that particular combination of features, you > end up with a filesystem that can be inconsistent: there's a race > condition between updating the data in a file and updating the csum > record for it, and the race can't be fixed.
... Which is both why btrfs disables checksumming on nocow, and why more traditional in-place-overwrite filesystems don't normally offer a checksumming feature -- it's only easily and reliably possible with copy- on-write, as in-place-overwrite introduces race issues that are basically impossible to solve. Logging can narrow the race, but consider, either they introduce some level of copy-on-write themselves, or one way or another, you're going to have to write two things, one a checksum of the other, and if they are in- place-overwrites, while the race can be narrowed, there's always going to be a point at which either one or the other will have been written, while the other hasn't been, and if failure occurs at that point... The only real way around that is /some/ form of copy-on-write, such that both the change and its checksum can be written to a different location than the old version, with a single, atomic write then updating a pointer to point to the new version of both the data and its checksum, instead of the old one. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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
