Re: FYIO: A rant about btrfs

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

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

On 2015-09-17 11:57, Martin Steigerwald wrote:
> Am Mittwoch, 16. September 2015, 23:29:30 CEST schrieb Hugo Mills:
>>> 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.
>>
>>     Indeed. The barriers are an ordering condition. The FS relies on
>> (i.e. *requires*) that ordering condition, in order to be truly
>> consistent. Running with "nobarrier" is a very strong signal that you
>> really don't care about the data on the FS.
>>
>>     This is not a case of me simply believing that because I've been
>> using btrfs for so long that I've got used to the peculiarities. The
>> first time I heard about the nobarrier option, something like 6 years
>> ago when I was first using btrfs, I thought "that's got to be a really
>> silly idea". Any complex data structure, like a filesystem, is going
>> to rely on some kind of ordering guarantees, somewhere in its
>> structure. (The ordering might be strict, with a global clock, or
>> barrier-based, or lattice-like, as for example a vector clock, but
>> there's going to be _some_ concept of order). nobarrier allows the FS
>> to ignore those guarantees, and even without knowing anything about
>> the FS at all, doing so is a big red DANGER flag.
>
> Official recommendation for XFS differs from that:
>
>   Q. Should barriers be enabled with storage which has a persistent write
> cache?
>
> Many hardware RAID have a persistent write cache which preserves it across
> power failure, interface resets, system crashes, etc. Using write barriers in
> this instance is not recommended and will in fact lower performance.
> Therefore, it is recommended to turn off the barrier support and mount the
> filesystem with "nobarrier", assuming your RAID controller is infallible and
> not resetting randomly like some common ones do. But take care about the hard
> disk write cache, which should be off.
>
> http://xfs.org/index.php/
> XFS_FAQ#Q._Should_barriers_be_enabled_with_storage_which_has_a_persistent_write_cache.
> 3F
There's a difference there still, XFS isn't quite as dependent on 
ordering as BTRFS is, and they're also giving some other strict 
rquirements (hard-disk write-cache being off (which I see a rather large 
number of people ignore), and a high-end RAID controller).



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