From: Shaohua Li <shli@kernel.org>
To: linux-block@vger.kernel.org, linux-raid@vger.kernel.org
Cc: kernel-team@fb.com, Kyungchan Koh <kyungchan.koh@gmail.com>,
Shaohua Li <shli@fb.com>
Subject: [PATCH V2 0/9] nullb: extend nullb for destructive tests
Date: Mon, 14 Aug 2017 15:04:51 -0700 [thread overview]
Message-ID: <cover.1502746933.git.shli@fb.com> (raw)
From: Shaohua Li <shli@fb.com>
In testing software RAID, I usually found it's hard to cover specific cases.
RAID is supposed to work even disk is in semi good state, for example, some
sectors are broken. Since we can't control the behavior of hardware, it's
difficult to create test suites to do the destructive tests. But we can control
the behavior of software, software based disk is an obvious choice for such
tests. While we already have several software based disks for testing (eg,
null_blk, scsi_debug), none is for destructive testing. Per Jens's request, we
extend null_blk to do the destructive testing.
To make this happen, we create new configfs interface for null_blk and added
some test features in null_blk:
- Bandwidth control. A raid array consists of several disks. The disks could
run in different speed, for example, one disk is SSD and the other is HD.
Actually raid1 has a feature called write behind just for this. To test such
raid1 feature, we'd like the disks speed could be controlled.
- Emulate disk cache. Software must flush disk cache to guarantee data is
safely stored in media after a power failure. To verify if software works
well, we can't simply use physical disk, because even software doesn't flush
cache, the hardware probably will flush the cache. With a software
implementation of disk cache, we can fully control how we flush disk cache in a
power failure.
- Badblock. If only part of a disk is broken, software raid continues working.
To test if software raid works well, disks must include some broken parts or
bad blocks. Bad blocks can be easily implemented in software.
To maintain compatibility, old null_blk module parameter interface is kept,
user can still create disks with it. Those disks aren't controlled by configfs
interface. Configfs interface will create/delete new disks. New features added
in the patchset will only be available with configfs interface.
While this is inspired by software raid testing, the interface is very
flexible for extension. We can easily add new features into the driver. The
interface is configfs, which can be configured with a shell script. There is a
'features' attribute exposing all supported features. By checking this, we
don't need to worry about compability issues. For configuration details, please
check the second patch.
This is Kyungchan Koh's intern project. I made some changes and adopted to
null_blk, all errors are mine. You are more than welcomed to test and add new
features!
Thanks,
Shaohua
Shaohua Li (9):
nullb: factor disk parameters
nullb: add configfs interface
nullb: add interface to power on disk
nullb: use ida to manage index
nullb: support memory backed store
nullb: support discard
nullb: bandwidth control
nullb: emulate cache
nullb: badbblocks support
drivers/block/Kconfig | 1 +
drivers/block/null_blk.c | 1303 ++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 1214 insertions(+), 90 deletions(-)
--
2.9.5
next reply other threads:[~2017-08-14 22:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-14 22:04 Shaohua Li [this message]
2017-08-14 22:04 ` [PATCH V2 1/9] nullb: factor disk parameters Shaohua Li
2017-08-14 22:04 ` [PATCH V2 2/9] nullb: add configfs interface Shaohua Li
2017-08-14 22:04 ` [PATCH V2 3/9] nullb: add interface to power on disk Shaohua Li
2017-08-14 22:04 ` [PATCH V2 4/9] nullb: use ida to manage index Shaohua Li
2017-08-14 22:04 ` [PATCH V2 5/9] nullb: support memory backed store Shaohua Li
2017-08-14 22:04 ` [PATCH V2 6/9] nullb: support discard Shaohua Li
2017-08-14 22:04 ` [PATCH V2 7/9] nullb: bandwidth control Shaohua Li
2017-08-14 22:04 ` [PATCH V2 8/9] nullb: emulate cache Shaohua Li
2017-08-16 17:00 ` Wols Lists
2017-08-14 22:05 ` [PATCH V2 9/9] nullb: badbblocks support Shaohua Li
2017-08-23 14:54 ` [PATCH V2 0/9] nullb: extend nullb for destructive tests Jens Axboe
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=cover.1502746933.git.shli@fb.com \
--to=shli@kernel.org \
--cc=kernel-team@fb.com \
--cc=kyungchan.koh@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=shli@fb.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;
as well as URLs for NNTP newsgroup(s).