On 2015-09-17 11:57, Martin Steigerwald wrote:
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).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
smime.p7s
Description: S/MIME Cryptographic Signature
