From: Christoph Hellwig <hch@lst.de>
To: Brian Foster <bfoster@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>,
zlang@kernel.org, djwong@kernel.org, fstests@vger.kernel.org,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: test log recovery for extent frees right after growfs
Date: Tue, 10 Sep 2024 17:10:53 +0200 [thread overview]
Message-ID: <20240910151053.GA22643@lst.de> (raw)
In-Reply-To: <ZuBVhszqs-fKmc9X@bfoster>
On Tue, Sep 10, 2024 at 10:19:50AM -0400, Brian Foster wrote:
> No real issue with the test, but I wonder if we could do something more
> generic. Various XFS shutdown and log recovery issues went undetected
> for a while until we started adding more of the generic stress tests
> currently categorized in the recoveryloop group.
>
> So for example, I'm wondering if you took something like generic/388 or
> 475 and modified it to start with a smallish fs, grew it in 1GB or
> whatever increments on each loop iteration, and then ran the same
> generic stress/timeout/shutdown/recovery sequence, would that eventually
> reproduce the issue you've fixed? I don't think reproducibility would
> need to be 100% for the test to be useful, fwiw.
>
> Note that I'm assuming we don't have something like that already. I see
> growfs and shutdown tests in tests/xfs/group.list, but nothing in both
> groups and I haven't looked through the individual tests. Just a
> thought.
It turns out reproducing this bug was surprisingly complicated.
After a growfs we can now dip into reserves that made the test1
file start filling up the existing AGs first for a while, and thus
the error injection would hit on that and never even reach a new
AG.
So while agree with your sentiment and like the highlevel idea, I
suspect it will need a fair amount of work to actually be useful.
Right now I'm too busy with various projects to look into it
unfortunately.
next prev parent reply other threads:[~2024-09-10 15:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 4:31 [PATCH] xfs: test log recovery for extent frees right after growfs Christoph Hellwig
2024-09-10 8:57 ` Zorro Lang
2024-09-10 11:34 ` Christoph Hellwig
2024-09-10 14:19 ` Brian Foster
2024-09-10 15:10 ` Christoph Hellwig [this message]
2024-09-10 16:13 ` Brian Foster
2024-10-08 16:28 ` Brian Foster
2024-10-09 8:04 ` Christoph Hellwig
2024-10-09 12:35 ` Brian Foster
2024-10-09 12:43 ` Christoph Hellwig
2024-10-09 15:14 ` Brian Foster
2024-10-10 6:51 ` Christoph Hellwig
2024-10-14 6:00 ` Christoph Hellwig
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=20240910151053.GA22643@lst.de \
--to=hch@lst.de \
--cc=bfoster@redhat.com \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@kernel.org \
/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.