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 Thanks, -- Martin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
