[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250421155433.GC25700@frogsfrogsfrogs>
Date: Mon, 21 Apr 2025 08:54:33 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Theodore Ts'o <tytso@....edu>
Cc: Luis Chamberlain <mcgrof@...nel.org>, adilger.kernel@...ger.ca,
linux-ext4@...r.kernel.org, kdevops@...ts.linux.dev,
dave@...olabs.net, jack@...e.cz
Subject: Re: ext4 v6.15-rc2 baseline
On Sat, Apr 19, 2025 at 01:22:49PM -0500, Theodore Ts'o wrote:
> On Thu, Apr 17, 2025 at 01:56:29PM -0700, Luis Chamberlain wrote:
> >
> > Perhaps something like (not tested):
> >
> > From a9386348701e387942e3eaaef8ee9daac8ace16a Mon Sep 17 00:00:00 2001
> > From: Luis Chamberlain <mcgrof@...nel.org>
> > Date: Thu, 17 Apr 2025 13:54:25 -0700
> > Subject: [PATCH] ext4: add ordered requirement for generic/04[456]
> >
> > generic/04[456] tests how truncate and delayed allocation works.
> > ext4 uses the data=ordered to avoid exposing stale data, and
> > so it uses a different mechanism than xfs. So these tests will fail
> > on it.
>
> No, you misunderstand the problem. The generic/04[456] tests are
> checking for a specific implementation detail in how xfs works to
> prevent stale data from being exposing data after a crash. Ext4 has a
> different method for achieving the same goal, using data=ordered,
> which is the default. So checking for data=ordered isn't necessary,
> because it is the default. But how it achieves thinigs means that
> these tests, which tests for a specific implementation, doesn't work.
>
> Fundamentally, these tests check what happens when you are writing to
> a file and the file system is shutdown (simulating a power failure).
> Exaclty how this handled is not guaranteed by POSIX, so testing for a
> specific behaviour is in my opinion, not really that great of an idea.
> In any case, the fact that we don't do exactly what these tests are
> expecting is not a problem as far as I'm concerned, and so we skip
> them.
I might be wading in deeper than I know, but it seems to me that
after a crash recovery it's not great to see 64k files with no blocks
allocated to them at all. That probably falls into "fs crash behavior
isn't guaranteed by POSIX", but if that's the case then these three
tests (generic/044-046) should _exclude_fs ext3 ext4 and explain why.
(I don't care about the others whining about _exclude_fs-- if you make
the design decision that the current ext4 behavior is good enough, then
the test cannot ever be satisfied so let's capture that in the test
itself, not in everyone's scattered exclusion lists.)
--D
> Cheers,
>
> - Ted
Powered by blists - more mailing lists