On Thu, May 23, 2019 at 10:34 AM Adam Borowski <kilobyte@xxxxxxxxxx> wrote: > > 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. I would not mind a mount option to ignore application fsync and fdatasync, while maintaining the Btrfs data->metadata->super write order guarantee. I'd expect that would be a more commonly preferred use case than volatile/disposable file systems. But what do you suppose the real world performance increase is between the former and latter? -- Chris Murphy
