All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@gmail.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Wang Yugui <wangyugui@e16-tech.com>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: 'ls /mnt/scratch/' freeze(deadlock?) when run xfstest(btrfs/232)
Date: Thu, 22 Apr 2021 11:59:48 +0100	[thread overview]
Message-ID: <CAL3q7H6cC+PrrxjozYYFV7wH7LUsS0mf=7djHccJ0J6E0c+Bmw@mail.gmail.com> (raw)
In-Reply-To: <9b4400ca-d0a3-621d-591c-dc377d0bed58@gmx.com>

On Thu, Apr 22, 2021 at 12:19 AM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> On 2021/4/22 上午12:03, Filipe Manana wrote:
> > On Wed, Apr 21, 2021 at 4:57 PM Wang Yugui <wangyugui@e16-tech.com> wrote:
> >>
> >> Hi,
> >>
> >>> That's the problem, qgroup flushing triggers writeback for an inode
> >>> for which we have a page dirtied and locked.
> >>> This should fix it:  https://pastebin.com/raw/U9GUZiEf
> >>>
> >>> Try it out and I'll write a changelog later.
> >>> Thanks.
> >>
> >> we run xfstest on two server with this patch.
> >> one passed the tests.
> >> but one got a btrfs/232 error.
> >>
> >> btrfs/232 32s ... _check_btrfs_filesystem: filesystem on /dev/nvme0n1p1 is inconsistent
> >> (see /usr/hpc-bio/xfstests/results//btrfs/232.full for details)
> >> ...
> >> [4/7] checking fs roots
> >> root 5 inode 337 errors 400, nbytes wrong
> >> ERROR: errors found in fs roots
> >
> > Ok, that's a different problem caused by something else.
> > It's possible to be due to the recent refactorings for preparation to
> > subpage block size.
>
> This error looks exactly what I have seen during subpage development.
> The subpage bug is caused by incorrect btrfs_invalidatepage() though,
> and not yet merged into misc-next anyway.

Ok, I vaguely remembered you encountering problems with that and
mentioning it somewhere.
I couldn't reproduce it overnight.

>
> I guess it's some error path not clearing extent states correctly, thus
> leaving the inode nbytes accounting wrong.
>
> BTW, the new @in_reclaim_context parameter for start_delalloc_inodes()
> is already in misc-next:

Well, yes, it was added to 5.11 and then backported to the relevant
stable releases.

> commit 3d45f221ce627d13e2e6ef3274f06750c84a6542
> Author: Filipe Manana <fdmanana@suse.com>
> Date:   Wed Dec 2 11:55:58 2020 +0000
>
>      btrfs: fix deadlock when cloning inline extent and low on free
> metadata space
>
> We only need to make btrfs_start_delalloc_snapshot() to accept the new
> parameter and pass in_reclaim_context = true for qgroup.

Correct.
I initially thought about removing the argument and always skip the
flagged inodes, but that would make snapshotting not wait for inline
cloning in progress (which is why I introduced the parameter back
then).
Not that it could cause any problem, just a matter of being consistent
and preserving the behaviour of waiting for any ongoing inline extent
cloning.

>
> Thanks,
> Qu
> >
> > Will try to look into that later.
> >
> > Thanks.
> >
> >> ...
> >>
> >> Best Regards
> >> Wang Yugui (wangyugui@e16-tech.com)
> >> 2021/04/21
> >>
> >
> >



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

      parent reply	other threads:[~2021-04-22 11:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-21  0:31 'ls /mnt/scratch/' freeze(deadlock?) when run xfstest(btrfs/232) Wang Yugui
2021-04-21 12:17 ` Wang Yugui
2021-04-21 13:29   ` Filipe Manana
2021-04-21 15:57     ` Wang Yugui
2021-04-21 16:03       ` Filipe Manana
2021-04-21 23:19         ` Qu Wenruo
2021-04-21 23:43           ` Qu Wenruo
2021-04-22  0:32             ` Wang Yugui
2021-04-22  0:57               ` Qu Wenruo
2021-04-22  1:25                 ` Wang Yugui
2021-04-22  4:16                 ` Wang Yugui
2021-04-22 11:06                   ` Filipe Manana
2021-04-22 10:59           ` Filipe Manana [this message]

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='CAL3q7H6cC+PrrxjozYYFV7wH7LUsS0mf=7djHccJ0J6E0c+Bmw@mail.gmail.com' \
    --to=fdmanana@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wangyugui@e16-tech.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.