All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: "Darrick J. Wong" <djwong@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: Sat, 19 Apr 2025 13:22:49 -0500	[thread overview]
Message-ID: <20250419182249.GC210438@mit.edu> (raw)
In-Reply-To: <aAFq_bef9liguosY@bombadil.infradead.org>

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.

Cheers,

						- Ted

  reply	other threads:[~2025-04-19 18:23 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 [this message]
2025-04-21 15:54           ` Darrick J. Wong
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=20250419182249.GC210438@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=dave@stgolabs.net \
    --cc=djwong@kernel.org \
    --cc=jack@suse.cz \
    --cc=kdevops@lists.linux.dev \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mcgrof@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.