On Thu, May 23, 2019 at 10:24:28AM -0600, Chris Murphy wrote: > On Thu, May 23, 2019 at 5:19 AM Austin S. Hemmelgarn > > BTRFS explicitly requests write barriers to prevent that type of > > reordering of writes from happening, and it's actually pretty unusual on > > modern hardware for those write barriers to not be honored unless the > > user is doing something stupid (like mounting with 'nobarrier' or using > > LVM with write barrier support disabled). > > 'man xfs' > > barrier|nobarrier > Note: This option has been deprecated as of kernel > v4.10; in that version, integrity operations are always performed and > the mount option is ignored. These mount options will be removed no > earlier than kernel v4.15. > > Since they're getting rid of it, I wonder if it's sane for most any > sane file system use case.
A volatile filesystem: one that you're willing to rebuild from scratch (or backups) on power loss. This includes any filesystem in a volatile VM. Example use case: a build machine, where the build filesystem wants btrfs for snapshots (the build environment several minutes to recreate), yet with the environment recreated weekly, a crash can be considered an additional start of a week. :) Or, some clusters consider a crashed node to be dead and needing rebuild; the filesystem's contents will be cloned from a master anyway. In all of these cases, fsyncs can be ignored as well. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ At least spammers get it right: "Hello beautiful!". ⠈⠳⣄⠀⠀⠀⠀
