From: Christoph Hellwig <hch@infradead.org>
To: Daniel Wagner <dwagner@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
Stephen Zhang <starzhangzsd@gmail.com>,
Kent Overstreet <kent.overstreet@linux.dev>,
Coly Li <colyli@fnnas.com>,
Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org
Subject: Re: [PATCH blktests] bcache: add bcache/001
Date: Wed, 21 Jan 2026 22:35:12 -0800 [thread overview]
Message-ID: <aXHFIM-8HrO-8cCO@infradead.org> (raw)
In-Reply-To: <512c18ed-feed-416d-9de6-c9183da98efc@flourine.local>
On Wed, Jan 21, 2026 at 01:48:27PM +0100, Daniel Wagner wrote:
> Sure, I'll update the documentation.
>
> On this note, It took me a while to understand that using
> TEST_DEVS="/dev/nvme0n1 /dev/vdb /dev/vdc" is not populating the
> TEST_DEV_ARRAY array.
>
> Commit 653ace845911 ("check, new: introduce test_device_array()")
> explains why:
>
> As to the test target devices defined in TEST_DEVS variable, blktests
> assumes that each test case with test_device() function is run for each
> single device defined in TEST_DEVS. On the other hand, it is suggested
> to support a test case for not a single device but multiple devices.
>
> Maybe we could add a default config with all options listed and
> documented but commented out.
The default config would be useful for sure.
But I also thing the TEST_DEVS vs TEST_DEV_ARRAY thing is weird, and the
fact that you need to declare the array for multiple tests doesn't help.
IMHO having a TEST_DEV_ARRAY should imply that normal single device tests
pick the first one from it if not explicit TEST_DEVS is set, and tests
using multiple devices can grab as many as they support from it. That
would mirror what SCRATCH_DEV_POOL does in xfstests, which works very
well.
I'd love to help with this, but I'm not sure my bash abilities are
enough for this :(
next prev parent reply other threads:[~2026-01-22 6:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 13:28 [PATCH blktests] bcache: add bcache/001 Daniel Wagner
2026-01-21 7:56 ` Christoph Hellwig
2026-01-21 12:48 ` Daniel Wagner
2026-01-22 6:35 ` Christoph Hellwig [this message]
2026-01-22 9:13 ` Shinichiro Kawasaki
2026-01-21 8:19 ` Johannes Thumshirn
2026-01-21 12:36 ` Daniel Wagner
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=aXHFIM-8HrO-8cCO@infradead.org \
--to=hch@infradead.org \
--cc=colyli@fnnas.com \
--cc=dwagner@suse.de \
--cc=kent.overstreet@linux.dev \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=shinichiro.kawasaki@wdc.com \
--cc=starzhangzsd@gmail.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 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.