[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260216131308.atxnkqehyke4conu@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>
Date: Mon, 16 Feb 2026 21:13:08 +0800
From: Zorro Lang <zlang@...hat.com>
To: Jan Kara <jack@...e.cz>
Cc: Zorro Lang <zlang@...nel.org>, fstests@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-xfs@...r.kernel.org
Subject: Re: [PATCH 0/4] Avoid failing shutdown tests without a journal
On Mon, Feb 16, 2026 at 09:56:07AM +0100, Jan Kara wrote:
> On Fri 13-02-26 00:44:02, Zorro Lang wrote:
> > On Thu, Feb 12, 2026 at 11:41:59AM +0100, Jan Kara wrote:
> > > > I initially considered calling _require_metadata_journaling directly inside
> > > > _require_scratch_shutdown. However, I decided against it because some cases might
> > > > only need the shutdown ioctl and don't strictly require a journal.
> > >
> > > Absolutely. I think they should stay separate.
> > >
> > > So to summarize I think we should still add _require_metadata_journaling to:
> > >
> > > overlay/087
> > > g/536
> > > g/622
> > > g/722
> >
> > Agree :)
>
> Should I send patches or will you do this modification?
As you brought this issue up, so I'd like to leave the finish line to you :)
I saw your 4 patches nearly use same subject and commit log too. If you fix more 4 cases,
we'll have 8 seperated patches :-D So how about squashing all changes into one single
patch? Does that make sense to you?
Thanks,
Zorro
>
> > > and we might add fsync of parent directory before shutdown to g/737 and
> > > overlay/078. Does this sound good?
> >
> > I'm concerned that adding broader sync or fsync operations might interfere with the
> > test's original intent. We should probably evaluate the impact further. Alternatively,
> > we could simply use _require_metadata_journaling to ensure we at least keep the
> > coverage for the original bug :)
>
> I agree with the approach to just leave the test as is for now and invest time
> into deciding what's the proper solution once someone complains :)
>
> Honza
> --
> Jan Kara <jack@...e.com>
> SUSE Labs, CR
>
Powered by blists - more mailing lists