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: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to