On 2019-05-23 12:46, Chris Murphy wrote:
On Thu, May 23, 2019 at 10:34 AM Adam Borowski <kilob...@angband.pl> 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?
There's a LD_PRELOAD for that!
Search 'libeatmydata' or 'eatmydata' in your preferred distro's package
manager, most of them have it. It's an LD_PRELOAD library that stubs
out fsync and fdatasync. Realistically, how much it helps is _really_
dependent on the application. Some package managers can see huge
benefits because they call fsync regularly (for example, APT on Debian
can show a big improvement, because each call it makes to dpkg that
actually modifies system state makes at least 1 call to fsync, usually
more).
