| commit | 48b54d444b53f2606acecd892c84d4f98a5f2be9 | [log] [tgz] |
|---|---|---|
| author | Omar Sandoval <osandov@fb.com> | Thu Dec 20 22:12:03 2018 |
| committer | Omar Sandoval <osandov@fb.com> | Thu Dec 20 22:25:43 2018 |
| tree | 4b6e891d85f436c1b33971466f1e4dc5ae65a0c7 | |
| parent | 2ddd30d4a9a47003efc3ffb5edf8130691edc66c [diff] |
Add a test for the blk-mq direct issue corruption This is based on a fio job from Jens with the following description: This job file does: One write/read verify set, using 256M of files, each 1M. The reader part runs 16 times, and in two jobs, while the next write/read verify set starts. This set is much larger, it's mainly meant to generate write based IO with frequent fsyncs. The fsyncs are key, as they do not queue on SATA. This means that the other reads (or writes) can get a BUSY condition off direct issue, and with lots of other IO going, stay around for a longer time before getting re-issued. This increases the chances of a merge happening before they are re-issued. I cannot reproduce this on bare metal, tried a lot of different boxes. What does work reliably for me is a qemu setup, with 1 CPU, and limited to 400M of RAM. The drive used for testing should be the following: -drive file=scsi.raw,media=disk,if=ide created with: qemu-img create -f raw scsi.raw 10G The machine type used with qemu was -machine q35,accel=kvm Once booted, ensure that sda (if that's the drive above) is not using an IO scheduler: echo none > /sys/block/sda/queue/scheduler Then just normally mkfs + mount the device, and run this job file in the mount point. Thanks to Lukáš Krejčí for describing how he reproduced it, the qemu setup above is directly based on his description. I.e., it only reproduces the bug under certain conditions, but it's still valuable enough to have a fio verify test. Signed-off-by: Omar Sandoval <osandov@fb.com>
blktests is a test framework for the Linux kernel block layer and storage stack. It is inspired by the xfstests filesystem testing framework.
The dependencies are minimal, but make sure you have them installed:
Some tests require the following:
Build blktests with make. Optionally, install it to a known location with make install (/usr/local/blktests by default, but this can be changed by passing DESTDIR and/or prefix).
Add the list of block devices you want to test on in a file named config:
TEST_DEVS=(/dev/nvme0n1 /dev/sdb)
And as root, run the default set of tests with ./check.
Note that these tests are destructive, so don't add anything to the TEST_DEVS array containing data that you want to keep.
See here for more detailed information on configuration and running tests.
The ./new script creates a new test from a template. The generated template contains more detailed documentation.
Pull requests on GitHub and patches to linux-block@vger.kernel.org are both accepted. See here for more information on contributing.