Re: FYIO: A rant about btrfs

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]

On 2015-09-16 12:25, Zia Nayamuth wrote:
> 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).
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.
>
> 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?
>
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.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]