On Wed, Sep 16, 2015 at 03:04:38PM -0400, Vincent Olivier wrote: > > On Sep 16, 2015, at 2:22 PM, Austin S Hemmelgarn <ahferro...@gmail.com> > > wrote: > > On 2015-09-16 12:51, Vincent Olivier wrote: > >>> On Sep 16, 2015, at 11:20 AM, Austin S Hemmelgarn <ahferro...@gmail.com> > >>> wrote: > >>> On 2015-09-16 10:43, M G Berberich wrote: > >>> It is worth noting a few things that were done incorrectly in this > >>> testing: > >>> 1. _NEVER_ turn off write barriers (nobarrier mount option), doing so > >>> subtly breaks the data integrity guarantees of _ALL_ filesystems, but > >>> especially so on COW filesystems like BTRFS. With this off, you will > >>> have a much higher chance that a power loss will cause data loss. It > >>> shouldn't be turned off unless you are also turning off write-caching in > >>> the hardware or know for certain that no write-reordering is done by the > >>> hardware (and almost all modern hardware does write-reordering for > >>> performance reasons). > >> But can the “nobarrier” mount option affect performances negatively for > >> Btrfs (and not only data integrity)? > > Using it improves performance for every filesystem on Linux that supports > > it. This does not mean that it is _EVER_ a good idea to do so. This mount > > option is one of the few things on my list of things that I will _NEVER_ > > personally provide support to people for, because it almost guarantees that > > you will lose data if the system dies unexpectedly (even if it's for a > > reason other than power loss). > > OK fine. Let it be clearer then (on the Btrfs wiki): nobarrier is an absolute > no go. Case closed.
Sometimes it is useful to make an ephemeral filesystem, i.e. a btrfs on a dm-crypt device with a random key that is not stored. This configuration intentionally and completely destroys the entire filesystem, and all data on it, in the event of a power failure. It's useful for things like temporary table storage, where ramfs is too small, swap-backed tmpfs is too slow, and/or there is a requirement that the data not be persisted across reboots. In other words, nobarrier is for a little better performance when you already want to _intentionally_ destroy your filesystem on power failure.
signature.asc
Description: Digital signature
