public inbox for kdevops@lists.linux.dev
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
	kdevops@lists.linux.dev, dave@stgolabs.net, jack@suse.cz
Subject: Re: ext4 v6.15-rc2 baseline
Date: Mon, 21 Apr 2025 08:54:33 -0700	[thread overview]
Message-ID: <20250421155433.GC25700@frogsfrogsfrogs> (raw)
In-Reply-To: <20250419182249.GC210438@mit.edu>

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@kernel.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

  reply	other threads:[~2025-04-21 15:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-16 17:56 ext4 v6.15-rc2 baseline Luis Chamberlain
2025-04-16 23:34 ` Theodore Ts'o
2025-04-17 16:38   ` Darrick J. Wong
2025-04-17 18:37     ` Theodore Ts'o
2025-04-17 20:56       ` Luis Chamberlain
2025-04-19 18:22         ` Theodore Ts'o
2025-04-21 15:54           ` Darrick J. Wong [this message]
2025-04-21 16:29             ` Theodore Ts'o
2025-04-21 16:47               ` Darrick J. Wong
2025-04-17 16:49   ` Theodore Ts'o
2025-04-17 20:35     ` Luis Chamberlain
2025-04-18  1:42       ` Luis Chamberlain
2025-04-18  3:56         ` Theodore Ts'o
2025-04-18 19:08           ` Luis Chamberlain
2025-04-19 18:36             ` Theodore Ts'o
2025-04-20  3:39               ` Theodore Ts'o

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=20250421155433.GC25700@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=dave@stgolabs.net \
    --cc=jack@suse.cz \
    --cc=kdevops@lists.linux.dev \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=tytso@mit.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox