Re: [PATCH 0/3] btrfs: fix fsync failure with SQL Server workload

On Tue, May 25, 2021 at 4:05 PM David Sterba [off-list ref] wrote:

On Mon, May 24, 2021 at 11:35:52AM +0100, fdmanana@kernel.org wrote:

quoted

From: Filipe Manana <redacted>

This patchset fixes a fsync failure (-EIO) and transaction abort during
a workload for Microsoft's SQL Server running in a Docker container as
reported at:

https://lore.kernel.org/linux-btrfs/93c4600e-5263-5cba-adf0-6f47526e7561@in.tum.de/ (local)

It also adds an optimization for the workload, by removing lots of fsyncs
that trigger the slow code path and replacing them with ones that use the
fast path, reducing the workload's runtime by about -12% on my test box.

Filipe Manana (3):
  btrfs: fix fsync failure and transaction abort after writes to
    prealloc extents
  btrfs: fix misleading and incomplete comment of btrfs_truncate()
  btrfs: don't set the full sync flag when truncation does not touch
    extents

Added to misc-next, thanks. I've marked the first patch for 5.4+. It
applies cleanly up to 4.4 but I'm not sure if this is safe given the
amount of other fixes that are mentioned in the patch and other fsync
related fixes that have been applied.

Should work on any 4.4+ kernel.
It's independent of the other mentioned fixes, as those were mostly
related to shared extents, except for one which was for the checksums
tree and unrelated to fsyncs.
I didn't add a Fixes tag because it's a really old thing, either
introduced when the fast fsync path was first added or when fallocate
was added, or somewhere in between.
The fsync failure and transaction abort only happen since the tree
checker was changed to detect overlapping checksum items (5.10, commit
ad1d8c439978ede77cbf73cbdd11bafe810421a5),
before that any issue would only happen at log replay time. 5.4+
sounds very reasonable to me. Thanks.