From: Brian Foster <bfoster@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Zorro Lang <zlang@redhat.com>,
"Darrick J. Wong" <djwong@kernel.org>,
linux-xfs@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH 01/12] generic/757: fix various bugs in this test
Date: Fri, 22 Nov 2024 08:49:42 -0500 [thread overview]
Message-ID: <Z0CL9mrUeHxgwFFg@bfoster> (raw)
In-Reply-To: <20241122123133.GA26198@lst.de>
On Fri, Nov 22, 2024 at 01:31:33PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 21, 2024 at 09:11:56AM -0500, Brian Foster wrote:
> > > I'm all for speeding up tests. But relying on a unspecified side effect
> > > of an operation and then requiring a driver that implements that side
> > > effect without documenting that isn't really good practice.
> > >
> >
> > It's a hack to facilitate test coverage. It would obviously need to be
> > revisited if behavior changed sufficiently to break the test.
> >
> > I'm not really sure what you're asking for wrt documentation. A quick
> > scan of the git history shows the first such commit is 65cc9a235919
> > ("generic/482: use thin volume as data device"), the commit log for
> > which seems to explain the reasoning.
>
> A comment on _log_writes_init that it must only be used by dm-thin
> because it relies on the undocumented behavior that dm-trim zeroes
> all blocks discarded.
>
> Or even better my moving the dm-think setup boilerplate into the log
> writes helpers, so that it gets done automatically.
>
A related idea might be to incorporate your BLKZEROOUT fix so the core
tool is fundamentally correct, but then wrap the existing discard
behavior in a param or something that the dm-thin oriented tests can
pass to enable it as a fast zero hack/optimization.
But that all seems reasonable to me either way. I'm not sure that's
something I would have fully abstracted into the logwrites stuff
initially, but here we are ~5 years later and it seems pretty much every
additional logwrites test has wanted the same treatment. If whoever
wants to convert this newer test over wants to start by refactoring
things that way, that sounds like a welcome cleanup to me.
Brian
next prev parent reply other threads:[~2024-11-22 13:48 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 23:01 [PATCHSET] fstests: random fixes for v2024.11.17 Darrick J. Wong
2024-11-18 23:01 ` [PATCH 01/12] generic/757: fix various bugs in this test Darrick J. Wong
2024-11-21 9:56 ` Zorro Lang
2024-11-21 10:05 ` Christoph Hellwig
2024-11-21 10:13 ` Christoph Hellwig
2024-11-21 10:52 ` Christoph Hellwig
2024-11-21 16:33 ` Darrick J. Wong
2024-11-21 17:19 ` Darrick J. Wong
2024-11-22 12:35 ` Christoph Hellwig
2024-11-21 12:28 ` Brian Foster
2024-11-21 13:12 ` Christoph Hellwig
2024-11-21 14:11 ` Brian Foster
2024-11-22 12:31 ` Christoph Hellwig
2024-11-22 13:49 ` Brian Foster [this message]
2024-11-22 16:13 ` Darrick J. Wong
2024-11-22 16:20 ` Christoph Hellwig
2024-11-22 16:33 ` Brian Foster
2024-11-22 16:37 ` Darrick J. Wong
2024-11-21 16:04 ` Darrick J. Wong
2024-11-22 12:34 ` Christoph Hellwig
2024-11-18 23:01 ` [PATCH 02/12] xfs/113: fix failure to corrupt the entire directory Darrick J. Wong
2024-11-18 23:02 ` [PATCH 03/12] xfs/508: fix test for 64k blocksize Darrick J. Wong
2024-11-18 23:02 ` [PATCH 04/12] common/rc: capture dmesg when oom kills happen Darrick J. Wong
2024-11-18 23:02 ` [PATCH 05/12] generic/562: handle ENOSPC while cloning gracefully Darrick J. Wong
2024-11-19 0:17 ` Filipe Manana
2024-11-19 0:31 ` Darrick J. Wong
2024-11-25 5:18 ` Darrick J. Wong
2024-11-18 23:02 ` [PATCH 06/12] xfs/163: skip test if we can't shrink due to enospc issues Darrick J. Wong
2024-11-19 6:11 ` Christoph Hellwig
2024-11-18 23:03 ` [PATCH 07/12] xfs/009: allow logically contiguous preallocations Darrick J. Wong
2024-11-19 6:11 ` Christoph Hellwig
2024-11-18 23:03 ` [PATCH 08/12] generic/251: use sentinel files to kill the fstrim loop Darrick J. Wong
2024-11-19 6:11 ` Christoph Hellwig
2024-11-18 23:03 ` [PATCH 09/12] generic/251: constrain runtime via time/load/soak factors Darrick J. Wong
2024-11-19 1:45 ` Dave Chinner
2024-11-19 6:13 ` Christoph Hellwig
2024-11-19 15:45 ` Darrick J. Wong
2024-11-19 21:04 ` Dave Chinner
2024-11-19 21:16 ` Darrick J. Wong
2024-11-19 15:50 ` Darrick J. Wong
2024-11-18 23:03 ` [PATCH 10/12] common/rc: _scratch_mkfs_sized supports extra arguments Darrick J. Wong
2024-11-18 23:04 ` [PATCH 11/12] xfs/157: do not drop necessary mkfs options Darrick J. Wong
2024-11-21 10:03 ` Zorro Lang
2024-11-18 23:04 ` [PATCH 12/12] xfs/157: fix test failures when MKFS_OPTIONS has -L options Darrick J. Wong
2024-11-21 10:17 ` Zorro Lang
2024-11-21 17:19 ` Darrick J. Wong
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=Z0CL9mrUeHxgwFFg@bfoster \
--to=bfoster@redhat.com \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
--cc=zlang@redhat.com \
/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