linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@kernel.org>
To: "François-Xavier Thomas" <fx.thomas@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Massive I/O usage from btrfs-cleaner after upgrading to 5.16
Date: Mon, 17 Jan 2022 12:02:08 +0000	[thread overview]
Message-ID: <YeVawBBE3r6hVhgs@debian9.Home> (raw)
In-Reply-To: <CAEwRaO4y3PPPUdwYjNDoB9m9CLzfd3DFFk2iK1X6OyyEWG5-mg@mail.gmail.com>

On Mon, Jan 17, 2022 at 11:06:42AM +0100, François-Xavier Thomas wrote:
> Hello all,
> 
> Just in case someone is having the same issue: Btrfs (in the
> btrfs-cleaner process) is taking a large amount of disk IO after
> upgrading to 5.16 on one of my volumes, and multiple other people seem
> to be having the same issue, see discussion in [0].
> 
> [1] is a close-up screenshot of disk I/O history (blue line is write
> ops, going from a baseline of some 10 ops/s to around 1k ops/s). I
> downgraded from 5.16 to 5.15 in the middle, which immediately restored
> previous performance.
> 
> Common options between affected people are: ssd, autodefrag. No error
> in the logs, and no other issue aside from performance (the volume
> works just fine for accessing data).
> 
> One person reports that SMART stats show a massive amount of blocks
> being written; unfortunately I do not have historical data for that so
> I cannot confirm, but this sounds likely given what I see on what
> should be a relatively new SSD.
> 
> Any idea of what it could be related to?

There was a big refactor of the defrag code that landed in 5.16.

On a quick glance, when using autodefrag it seems we now can end up in an
infinite loop by marking the same range for degrag (IO) over and over.

Can you try the following patch? (also at https://pastebin.com/raw/QR27Jv6n)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index a5bd6926f7ff..0a9f6125a566 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1213,6 +1213,13 @@ static int defrag_collect_targets(struct btrfs_inode *inode,
                if (em->generation < newer_than)
                        goto next;
 
+               /*
+                * Skip extents already under IO, otherwise we can end up in an
+                * infinite loop when using auto defrag.
+                */
+               if (em->generation == (u64)-1)
+                       goto next;
+
                /*
                 * For do_compress case, we want to compress all valid file
                 * extents, thus no @extent_thresh or mergeable check.


> 
> François-Xavier
> 
> [0] https://www.reddit.com/r/btrfs/comments/s4nrzb/massive_performance_degradation_after_upgrading/
> [1] https://imgur.com/oYhYat1

  reply	other threads:[~2022-01-17 12:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-17 10:06 François-Xavier Thomas
2022-01-17 12:02 ` Filipe Manana [this message]
2022-01-17 16:59   ` Filipe Manana
2022-01-17 21:37     ` François-Xavier Thomas
2022-01-19  9:44       ` François-Xavier Thomas
2022-01-19 10:13         ` Filipe Manana
2022-01-20 11:37           ` François-Xavier Thomas
2022-01-20 11:44             ` Filipe Manana
2022-01-20 12:02               ` François-Xavier Thomas
2022-01-20 12:45                 ` Qu Wenruo
2022-01-20 12:55                   ` Filipe Manana
2022-01-20 17:46                 ` Filipe Manana
2022-01-20 18:21                   ` François-Xavier Thomas
2022-01-21 10:49                     ` Filipe Manana
2022-01-21 19:39                       ` François-Xavier Thomas
2022-01-21 23:34                         ` Qu Wenruo
2022-01-22 18:20                           ` François-Xavier Thomas
2022-01-24  7:00                             ` Qu Wenruo
2022-01-25 20:00                               ` François-Xavier Thomas
2022-01-25 23:29                                 ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YeVawBBE3r6hVhgs@debian9.Home \
    --to=fdmanana@kernel.org \
    --cc=fx.thomas@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --subject='Re: Massive I/O usage from btrfs-cleaner after upgrading to 5.16' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).