On 2015-09-16 12:25, Zia Nayamuth wrote:
It's not as much of an issue if you have full power loss protection (assuming of course it works), but even then having write-barriers turned off is still not as safe as having them turned on. Most of the time when I've tried testing with 'nobarrier' (not just on BTRFS but on ext* as well), I had just as many issues with data loss when the system crashed as when it (simlated via killing the virtual machine) lost power. Both journaling and COW filesystems need to ensure ordering of certain write operations to be able to maintain consistency. For example, the new/updated data blocks need to be on disk before the metadata is updated to point to them, otherwise you database can end up corrupted.Some response to your criticism:1. How would that hole fare with a fully battery-backed/flash-backed path (battery-backed or flash-backed HBA with disks with full power-loss protection, like the Intel S3500)? In such a situation (quite commonplace in server-land), power-loss should not cause any data loss since all data in the cache is guaranteed to be committed to non-volatile memory at some point (whether such assurances may be trusted is another matter entirely though, and well outside the scope of this discussion).
My takeaway was that he intended 'general purpose use' to mean generic every day usage across a wide variety of systems, he was not particularly specific about it however.2. Fair point. I'd like to know his hardware, given how strongly hardware can influence things. 3. It's pretty obvious that the author of that blog is specifically targeting OLTP performance (explicit statement in intro, choice of benchmark, name and focus of blog), not common-case, and even states that in the first two paragraphs of his conclusion. The focus is somewhat less clear in said conclusion, namely, is he truly talking about general purpose use or is he talking about general purpose OLTP use?
smime.p7s
Description: S/MIME Cryptographic Signature
