On Wed, Sep 16, 2015 at 03:04:38PM -0400, Vincent Olivier wrote: > > On Sep 16, 2015, at 2:22 PM, Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> wrote: > > On 2015-09-16 12:51, Vincent Olivier wrote: > >>> On Sep 16, 2015, at 11:20 AM, Austin S Hemmelgarn <ahferroin7@xxxxxxxxx> 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.
Attachment:
signature.asc
Description: Digital signature
