osandov / blktests Goto Github PK

View Code? Open in Web Editor NEW

109.0 109.0 71.0 979 KB

Linux kernel block layer testing framework

Shell 81.64% Makefile 0.64% C 15.49% Emacs Lisp 0.06% C++ 2.18%

blktests's People

Contributors

Stargazers

Watchers

Forkers

axboe bvanassche morbidrsa colinianking wjn740 renzhengeek hreinecke nishita28 nagarathnam200 ddiss yizhanglinux felixsch alexxnica kryndex jeremycline josefbacik minwooim johnmeneghini dublio hhtrace xilabao shiqml javigon frankenmichl tytso im-0 dmonakhov linux-kern evangreen finallyjustice jkkm cgxu519 eideticom wxucnexlabs zhonggangchen igaw andrealmeid jrrk cualquiercosa327 schlad wubo009 zhijianli88 birkelund liangxiao1 persianyagami90xs abdhaleegit x-lugoo xcnix jderrick kamalheib sgzerolc xp4ns3 rainices nitesh-shetty panky-codes kawasaki legomushroom sachin-bappalige ablu xuyang0410 simonnie98 web-logs2 zhongchanghui tin-z hmadhani

blktests's Issues

Add -R option to blktests (similar to -R opton in xfstests)

I'm working on this right now; I aim at having as little changes to the check file as possible, so that we could possibly have something working in blktests soon and then I/we could improve on this further.

I try to add following "formats" to begin with: text, xunit.

It should produce single file report under $OUTPUT/

for text:
"text report generated on Mon May 11 11:23:17 CEST 2020

nodev loop/001
status pass
description scan loop device partitions
runtime 0.489s
date 2020-05-11 11:23:17
exit_status 0

nodev loop/007
status pass
description update loop device capacity with filesystem
runtime 0.949s
date 2020-05-11 11:23:18
exit_status 0

..."

function _get_pci_dev_from_blkdev doesn't work

Hi
On latest 4.14.0-rc5, the _get_pci_dev_from_blkdev function can get 4 pdev, which lead block/011 failed. Could we add "tail -1" at the end to fix it?
[1]

uname -r

4.14.0-rc5.EDAC+

lspci | grep -i non

84:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller 172X (rev 01)

[2]

readlink -f /sys/block/nvme0n1/device | grep -Eo '[0-9a-f]{4}:[0-9a-f]{2}:[0-9a-f]{2}.[0-9a-f]'

0000:80:02.0
0000:82:00.0
0000:83:04.0
0000:84:00.0

Thanks
Yi

block/017 fails because systemd tries to read it

Hi,

block/017 always fails on my test machine.

gkim@ib1:~/pb-ltp/blktests$ sudo ./check block/017
block/017 (do I/O and check the inflight counter)            [failed]
    runtime  58.937s  ...  58.952s
    --- tests/block/017.out	2018-10-26 00:39:35.516915128 +0200
    +++ /home/gkim/pb-ltp/blktests/results/nodev/block/017.out.bad	2019-04-02 11:08:55.659410586 +0200
    @@ -7,8 +7,8 @@
     sysfs inflight writes 1
     sysfs stat 2
     diskstats 2
    -sysfs inflight reads 0
    +sysfs inflight reads 1
     sysfs inflight writes 0
    -sysfs stat 0
    ...
    (Run 'diff -u tests/block/017.out /home/gkim/pb-ltp/blktests/results/nodev/block/017.out.bad' to see the entire diff)

I found out that systemd-udevd read it when /dev/nullb0 is created and it increased read-inflight count.
Do you have any idea to solve it?

gkim@ib1:~/pb-ltp/blktests$ sudo modprobe null_blk queue_mode=2 irqmode=2 completion_nsec=5000000000
[sudo] password for gkim: 
gkim@ib1:~/pb-ltp/blktests$ ls /sys/block/nullb0/inflight 
/sys/block/nullb0/inflight
gkim@ib1:~/pb-ltp/blktests$ cat /sys/block/nullb0/inflight 
       1        0
gkim@ib1:~/pb-ltp/blktests$ sudo fuser /dev/nullb0
/dev/nullb0:         31484
gkim@ib1:~/pb-ltp/blktests$ ps 31484
  PID TTY      STAT   TIME COMMAND
31484 ?        D      0:00 /lib/systemd/systemd-udevd
gkim@ib1:~/pb-ltp/blktests$ cat /sys/block/nullb0/inflight 
       1        0

I tried following patch but it did not work.

gkim@ib1:~/pb-ltp/blktests$ git diff
diff --git a/tests/block/017 b/tests/block/017
index e4a9259..faab514 100755
--- a/tests/block/017
+++ b/tests/block/017
@@ -32,6 +32,8 @@ test() {
                return 1
        fi
 
+       udevadm settle
+       
        dd if=/dev/nullb0 of=/dev/null bs=4096 iflag=direct count=1 status=none &
        sleep 0.1
        show_inflight

srp/** tests fails on power with error scsi_transport_srp is in use

The srp/** tests fails on power with below error.

./check tests/srp/001

srp/001 (Create and remove LUNs) [failed]
runtime 0.125s ... 0.132s
--- tests/srp/001.out 2023-12-25 09:40:30.000000000 +0530
+++ /home/blktests-master/results/nodev/srp/001.out.bad 2024-01-01 15:26:32.804759400 +0530
@@ -1,3 +1,4 @@
-Configured SRP target driver
-count_luns(): 3 <> 3
-Passed
+tests/srp/rc: line 263: /sys/class/srp_remote_ports/port-0:1/delete: Permission denied
+tests/srp/rc: line 263: /sys/class/srp_remote_ports/port-0:1/delete: Permission denied
+modprobe: FATAL: Module scsi_transport_srp is in use.
+failed to shutdown client
tests/srp/rc: line 263: /sys/class/srp_remote_ports/port-0:1/delete: Permission denied
tests/srp/rc: line 263: /sys/class/srp_remote_ports/port-0:1/delete: Permission denied
modprobe: FATAL: Module scsi_transport_srp is in use.

cat /home/blktests/results/nodev/srp/001.out.bad

tests/srp/rc: line 263: /sys/class/srp_remote_ports/port-0:1/delete: Permission denied
tests/srp/rc: line 263: /sys/class/srp_remote_ports/port-0:1/delete: Permission denied
modprobe: FATAL: Module scsi_transport_srp is in use.
failed to shutdown client

Which test checks for 201685 (ext4 corruption) ?

There is a comment by @axboe at

https://bugzilla.kernel.org/show_bug.cgi?id=201685#c288

to the effect that a test has been added to blktests to check for the ext4 file corruption issue described. Is that test in this test suite, and if so where is it?

nvme/033 failed

[root@rdma-client blktests]# TEST_DEVS=/dev/nvme0n1 nvme_trtype=rdma ./check nvme/033
nvme/033 => nvme0n1 (create and connect to an NVMeOF target with a passthru controller) [failed]
    runtime  2.562s  ...  2.561s
    --- tests/nvme/033.out      2022-05-11 12:06:52.956599746 +0800
    +++ /home/lizhijian/blktests/results/nvme0n1/nvme/033.out.bad       2022-06-02 11:55:51.772802585 +0800
    @@ -1,7 +1,10 @@                                                                                               
     Running nvme/033                                    
    -Discovery Log Number of Records 1, Generation counter X
    +Discovery Log Number of Records 2, Generation counter X
     =====Discovery Log Entry 0======
    -trtype:  loop                                       
    +trtype:  rdma                                       
    +subnqn:  nqn.2014-08.org.nvmexpress.discovery
    ...                                                  
    (Run 'diff -u tests/nvme/033.out /home/lizhijian/blktests/results/nvme0n1/nvme/033.out.bad' to see the entire diff)

the output of discovery as below:

[root@rdma-client blktests]# nvme discover -t rdma -a 192.168.122.78 -s 4420

Discovery Log Number of Records 2, Generation counter 2
=====Discovery Log Entry 0======
trtype:  rdma
adrfam:  ipv4
subtype: unrecognized
treq:    not specified, sq flow control disable supported
portid:  0
trsvcid: 4420
subnqn:  nqn.2014-08.org.nvmexpress.discovery
traddr:  192.168.122.78
rdma_prtype: not specified
rdma_qptype: connected
rdma_cms:    rdma-cm
rdma_pkey: 0x0000
=====Discovery Log Entry 1======
trtype:  rdma
adrfam:  ipv4
subtype: nvme subsystem
treq:    not specified, sq flow control disable supported
portid:  0
trsvcid: 4420
subnqn:  blktests-subsystem-1
traddr:  192.168.122.78
rdma_prtype: not specified
rdma_qptype: connected
rdma_cms:    rdma-cm
rdma_pkey: 0x0000

Failed case exit with 0 which introduced from e840e1537dc62dabfe9d59e5288b9318a2d7c50b

[root@storageqe-72 blktests]# git checkout e840e15
[root@storageqe-72 blktests]# ./check block/024
block/024 (do I/O faster than a jiffy and check iostats times) [failed]
runtime 2.514s ... 2.519s
--- tests/block/024.out 2019-02-15 07:25:04.391922614 +0100
+++ /mnt/tests/distribution/command/blktests/results/nodev/block/024.out.bad 2019-02-15 07:48:07.190199759 +0100
@@ -6,5 +6,5 @@
read 1 s
write 1 s
read 2 s
-write 3 s
+write 2 s
Test complete
[root@storageqe-72 blktests]# echo $?
0
[root@storageqe-72 blktests]# git reset --hard HEAD~1
HEAD is now at a58b974 loop: Add test for changing capacity when filesystem is mounted
[root@storageqe-72 blktests]# ./check block/024
block/024 (do I/O faster than a jiffy and check iostats times) [failed]
runtime 2.519s ... 2.509s
--- tests/block/024.out 2019-02-15 07:25:04.391922614 +0100
+++ /mnt/tests/distribution/command/blktests/results/nodev/block/024.out.bad 2019-02-15 07:48:31.308880877 +0100
@@ -6,5 +6,5 @@
read 1 s
write 1 s
read 2 s
-write 3 s
+write 2 s
Test complete
[root@storageqe-72 blktests]# echo $?
1

block/010 fail

I got this error log when running run_fio_job.
fio: ENOSPC on laying out file, stopping
And the null block doesn't support direct in my environment.
Is it necessary?

nvme/001 failed

kernel version: v4.17-rc6

nvme/001 => nvme0n1p1 (enable nvme_setup_nvm_cmd tracepoint and submit I/O to the device) [failed]
    runtime  ...  0.101s
    --- tests/nvme/001.out  2018-05-14 14:08:43.000000000 +0800
    +++ results/nvme0n1p1/nvme/001.out.bad  2018-05-25 12:01:41.623455896 +0800
    @@ -8,5 +8,5 @@
     #                            ||| /     delay
     #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
     #              | |       |   ||||       |         |
    -              dd-XXX   [XXX] ....    X.XXXXXX: nvme_setup_nvm_cmd: qid=X, nsid=X, cmdid=X, flags=0x0, meta=0x0, cmd=(nvme_cmd_read slba=0, len=0, ctrl=0x0, dsmgmt=0, reftag=0)
    +              dd-XXX  [XXX] ...2    X.XXXXXX: nvme_setup_nvm_cmd: qid=X, nsid=X, cmdid=X, flags=0x0, meta=0x0, cmd=(nvme_cmd_read slba=2048, len=0, ctrl=0x0, dsmgmt=0, reftag=0)
     Test complete

001.out.bad

Running nvme/001
# tracer: nop
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
              dd-XXX  [XXX] ...2    X.XXXXXX: nvme_setup_nvm_cmd: qid=X, nsid=X, cmdid=X, flags=0x0, meta=0x0, cmd=(nvme_cmd_read slba=2048, len=0, ctrl=0x0, dsmgmt=0, reftag=0)
Test complete

Shellcheck will help to clean up your code...

See: koalaman/shellcheck#2663

Those about $? (SC2320) are proof of bad coding, which you should correct...
https://github.com/osandov/blktests/blob/master/common/multipath-over-rdma#L134
Does this code have any chance of returning different return codes at all? 🤔 🤣
[ -n "$1" ] || return $?
I'm sure the rest are similar... 🤣

nbd/003 issue

lot of error logs found in dmesg log when executing nbd/003，please help to check it

it caused by https://github.com/osandov/blktests/blob/master/tests/nbd/003 line 25 src/mount_clear_sock /dev/nbd0 "${TMPDIR}/mnt" ext4 5000

# ./check nbd
nbd/001 (resize a connected nbd device)                      [passed]
    runtime  0.040s  ...  0.042s
nbd/002 (tests on partition handling for an nbd device)      [passed]
    runtime  2.167s  ...  2.156s
nbd/003 (mount/unmount concurrently with NBD_CLEAR_SOCK)     [passed]
    runtime  27.080s  ...  27.003s
nbd/004 (module load/unload concurrently with connect/disconnect) [passed]
    runtime  10.018s  ...  10.035s

# cat results/nodev/nbd/003.full 
Negotiation: ..size = 10240MB
bs=512, sz=10737418240 bytes
mke2fs 1.46.5 (30-Dec-2021)
Creating filesystem with 2621440 4k blocks and 655360 inodes
Filesystem UUID: b4a475df-c24a-4587-88bd-b63188dfed4d
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

dmesg log:

# dmesg
[20793.707213] nbd0: detected capacity change from 0 to 20971520
[21707.827337] block nbd0: shutting down sockets
[21707.831861] blk_print_req_error: 349 callbacks suppressed
[21707.831864] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[21707.845445] buffer_io_error: 36 callbacks suppressed
[21707.845446] Buffer I/O error on dev nbd0, logical block 0, async page read
[21707.857304] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[21707.865484] Buffer I/O error on dev nbd0, logical block 0, async page read
[21707.872367] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[21707.880549] Buffer I/O error on dev nbd0, logical block 0, async page read
[21707.887443] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[21707.895618] Buffer I/O error on dev nbd0, logical block 0, async page read
[21707.902499] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[21707.910675] Buffer I/O error on dev nbd0, logical block 0, async page read
[21707.917559] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[21707.925736] Buffer I/O error on dev nbd0, logical block 0, async page read
[21707.932618]  nbd0: unable to read partition table
[21707.932654] I/O error, dev nbd0, sector 2 op 0x0:(READ) flags 0x1000 phys_seg 1 prio class 0
[21707.941099] EXT4-fs (nbd0): unable to read superblock
[21707.941110] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 4 prio class 0
[21707.954322] Buffer I/O error on dev nbd0, logical block 0, async page read
[21707.961196] Buffer I/O error on dev nbd0, logical block 1, async page read
[21707.968070] Buffer I/O error on dev nbd0, logical block 2, async page read
[21707.974941] Buffer I/O error on dev nbd0, logical block 3, async page read
[21707.981825] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 4 prio class 0
[21707.990007] I/O error, dev nbd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 4 prio class 0
[21707.998202]  nbd0: unable to read partition table
[21707.998282]  nbd0: unable to read partition table
[21708.001495]  nbd0: unable to read partition table
[21708.001516] EXT4-fs (nbd0): unable to read superblock
[21708.006694]  nbd0: unable to read partition table
[21708.007205]  nbd0: unable to read partition table
[21708.007232] EXT4-fs (nbd0): unable to read superblock
[21708.007323]  nbd0: unable to read partition table
[21708.012702]  nbd0: unable to read partition table
[21708.012718] EXT4-fs (nbd0): unable to read superblock
[21708.018059] EXT4-fs (nbd0): unable to read superblock
[21708.023346] EXT4-fs (nbd0): unable to read superblock
[21708.028617] EXT4-fs (nbd0): unable to read superblock
[21708.033929] EXT4-fs (nbd0): unable to read superblock
[21708.039214] EXT4-fs (nbd0): unable to read superblock
[21708.044537] EXT4-fs (nbd0): unable to read superblock
[21708.049813] EXT4-fs (nbd0): unable to read superblock
[21708.055128] EXT4-fs (nbd0): unable to read superblock
[21708.060400] EXT4-fs (nbd0): unable to read superblock
[21708.065705] EXT4-fs (nbd0): unable to read superblock
[21708.070988] EXT4-fs (nbd0): unable to read superblock
[21708.076251] EXT4-fs (nbd0): unable to read superblock
[21708.081513] EXT4-fs (nbd0): unable to read superblock
[21708.086797] EXT4-fs (nbd0): unable to read superblock
[21708.092062] EXT4-fs (nbd0): unable to read superblock
[21708.097333] EXT4-fs (nbd0): unable to read superblock
[21708.102605] EXT4-fs (nbd0): unable to read superblock
[21708.107870] EXT4-fs (nbd0): unable to read superblock
[21708.113156] EXT4-fs (nbd0): unable to read superblock
[21708.118440] EXT4-fs (nbd0): unable to read superblock
[21708.123731] EXT4-fs (nbd0): unable to read superblock
[21708.128990] EXT4-fs (nbd0): unable to read superblock
[21708.134264] EXT4-fs (nbd0): unable to read superblock
[21708.139545] EXT4-fs (nbd0): unable to read superblock
[21708.144821] EXT4-fs (nbd0): unable to read superblock
[21708.150092] EXT4-fs (nbd0): unable to read superblock
[21708.155357] EXT4-fs (nbd0): unable to read superblock
[21708.160614] EXT4-fs (nbd0): unable to read superblock
[21708.165903] EXT4-fs (nbd0): unable to read superblock
[21708.171163] EXT4-fs (nbd0): unable to read superblock
[21708.176427] EXT4-fs (nbd0): unable to read superblock
[21708.181693] EXT4-fs (nbd0): unable to read superblock
[21708.186960] EXT4-fs (nbd0): unable to read superblock
[21708.192224] EXT4-fs (nbd0): unable to read superblock
[21708.197480] EXT4-fs (nbd0): unable to read superblock
[21708.202748] EXT4-fs (nbd0): unable to read superblock
[21708.208009] EXT4-fs (nbd0): unable to read superblock
[21708.213270] EXT4-fs (nbd0): unable to read superblock
[21708.218535] EXT4-fs (nbd0): unable to read superblock
[21708.223808] EXT4-fs (nbd0): unable to read superblock
[21708.229104] EXT4-fs (nbd0): unable to read superblock
[21708.234379] EXT4-fs (nbd0): unable to read superblock
[21708.239654] EXT4-fs (nbd0): unable to read superblock
[21708.244936] EXT4-fs (nbd0): unable to read superblock
[21708.250191] EXT4-fs (nbd0): unable to read superblock
[21708.255466] EXT4-fs (nbd0): unable to read superblock
[21708.260737] EXT4-fs (nbd0): unable to read superblock
[21708.266016] EXT4-fs (nbd0): unable to read superblock
[21708.271282] EXT4-fs (nbd0): unable to read superblock
[21708.276553] EXT4-fs (nbd0): unable to read superblock
[21708.281821] EXT4-fs (nbd0): unable to read superblock
[21708.287084] EXT4-fs (nbd0): unable to read superblock
[21708.292354] EXT4-fs (nbd0): unable to read superblock
[21708.297626] EXT4-fs (nbd0): unable to read superblock
[21708.302891] EXT4-fs (nbd0): unable to read superblock
[21708.308155] EXT4-fs (nbd0): unable to read superblock
[21708.313409] EXT4-fs (nbd0): unable to read superblock
[21708.318664] EXT4-fs (nbd0): unable to read superblock
[21708.323927] EXT4-fs (nbd0): unable to read superblock
[21708.329187] EXT4-fs (nbd0): unable to read superblock
[21708.334435] EXT4-fs (nbd0): unable to read superblock
[21708.339684] EXT4-fs (nbd0): unable to read superblock
[21708.344944] EXT4-fs (nbd0): unable to read superblock
[21708.350206] EXT4-fs (nbd0): unable to read superblock
[21708.355472] EXT4-fs (nbd0): unable to read superblock
[21708.360738] EXT4-fs (nbd0): unable to read superblock
[21708.365985] EXT4-fs (nbd0): unable to read superblock
[21708.371245] EXT4-fs (nbd0): unable to read superblock
[21708.376506] EXT4-fs (nbd0): unable to read superblock
[21708.381764] EXT4-fs (nbd0): unable to read superblock
[21708.387016] EXT4-fs (nbd0): unable to read superblock
[21708.392270] EXT4-fs (nbd0): unable to read superblock
[21708.397524] EXT4-fs (nbd0): unable to read superblock
[21708.402784] EXT4-fs (nbd0): unable to read superblock
[21708.408044] EXT4-fs (nbd0): unable to read superblock
[21708.413314] EXT4-fs (nbd0): unable to read superblock
[21708.418578] EXT4-fs (nbd0): unable to read superblock
[21708.423835] EXT4-fs (nbd0): unable to read superblock
[21708.429103] EXT4-fs (nbd0): unable to read superblock
[21708.434369] EXT4-fs (nbd0): unable to read superblock
[21708.439631] EXT4-fs (nbd0): unable to read superblock
[21708.444931] EXT4-fs (nbd0): unable to read superblock
[21708.450275] EXT4-fs (nbd0): unable to read superblock
[21708.455533] EXT4-fs (nbd0): unable to read superblock
[21708.460804] EXT4-fs (nbd0): unable to read superblock
[21708.466057] EXT4-fs (nbd0): unable to read superblock
[21708.471322] EXT4-fs (nbd0): unable to read superblock
[21708.476577] EXT4-fs (nbd0): unable to read superblock
[21708.481836] EXT4-fs (nbd0): unable to read superblock
[21708.487091] EXT4-fs (nbd0): unable to read superblock
[21708.492356] EXT4-fs (nbd0): unable to read superblock
[21708.497613] EXT4-fs (nbd0): unable to read superblock
[21708.502870] EXT4-fs (nbd0): unable to read superblock
[21708.508129] EXT4-fs (nbd0): unable to read superblock
[21708.513381] EXT4-fs (nbd0): unable to read superblock
[21708.518631] EXT4-fs (nbd0): unable to read superblock
[21708.523912] EXT4-fs (nbd0): unable to read superblock
[21708.529171] EXT4-fs (nbd0): unable to read superblock
[21708.534423] EXT4-fs (nbd0): unable to read superblock
[21708.539681] EXT4-fs (nbd0): unable to read superblock
[21708.544958] EXT4-fs (nbd0): unable to read superblock
[21708.550215] EXT4-fs (nbd0): unable to read superblock
[21708.555471] EXT4-fs (nbd0): unable to read superblock
[21708.560737] EXT4-fs (nbd0): unable to read superblock
[21708.565994] EXT4-fs (nbd0): unable to read superblock
[21708.571257] EXT4-fs (nbd0): unable to read superblock
[21708.576517] EXT4-fs (nbd0): unable to read superblock
[21708.581777] EXT4-fs (nbd0): unable to read superblock
[21708.587035] EXT4-fs (nbd0): unable to read superblock
[21708.592306] EXT4-fs (nbd0): unable to read superblock
[21708.597559] EXT4-fs (nbd0): unable to read superblock
.
.
.

Thanks,

Use 'set -o errexit' to catch script errors

Heya,

bash has the option 'errexit' (invoked via 'set -o errexit'), which will cause the script to abort if a command/line returns 'false'.
This has the nice effect that any errors are catched automatically, and don't have to be checked for.
With that we'll be able to catch silent failures which are currently ignored.
Drawback is that one gets lots of false positive initially, as every command which should be ignored need to be suffixed by ' || true'.

But it's a very good thing for hardening the scripts; I've had quite good experience with that when developing testcases for md_monitor

compiling error with make command

Hello
I met bellow error when do make command, did I missed something?
[root@storageqe-62 blktests]# make
make -C src all
make[1]: Entering directory /mnt/tests/kernel/storage/SSD/nvme_blktest/blktests/src' g++ -O2 -Wall -Wextra -Wno-sign-compare -o discontiguous-io discontiguous-io.cpp discontiguous-io.cpp: In member function ‘void iovec_t::append(void*, size_t)’: discontiguous-io.cpp:60:3: warning: ‘auto’ changes meaning in C++11; please remove it [-Wc++0x-compat] auto p = m_v.end() - 1; ^ discontiguous-io.cpp:60:8: error: ‘p’ does not name a type auto p = m_v.end() - 1; ^ discontiguous-io.cpp:61:3: error: ‘p’ was not declared in this scope p->iov_base = addr; ^ discontiguous-io.cpp: In member function ‘size_t iovec_t::data_len() const’: discontiguous-io.cpp:69:8: warning: ‘auto’ changes meaning in C++11; please remove it [-Wc++0x-compat] for (auto p = m_v.begin(); p != m_v.end(); ++p) ^ discontiguous-io.cpp:69:13: error: ‘p’ does not name a type for (auto p = m_v.begin(); p != m_v.end(); ++p) ^ discontiguous-io.cpp:69:30: error: expected ‘;’ before ‘p’ for (auto p = m_v.begin(); p != m_v.end(); ++p) ^ discontiguous-io.cpp:69:30: error: ‘p’ was not declared in this scope discontiguous-io.cpp: In member function ‘void iovec_t::trunc(size_t)’: discontiguous-io.cpp:75:8: warning: ‘auto’ changes meaning in C++11; please remove it [-Wc++0x-compat] for (auto p = m_v.begin(); p != m_v.end(); ++p) { ^ discontiguous-io.cpp:75:13: error: ‘p’ does not name a type for (auto p = m_v.begin(); p != m_v.end(); ++p) { ^ discontiguous-io.cpp:75:30: error: expected ‘;’ before ‘p’ for (auto p = m_v.begin(); p != m_v.end(); ++p) { ^ discontiguous-io.cpp:75:30: error: ‘p’ was not declared in this scope discontiguous-io.cpp: In member function ‘std::ostream& iovec_t::write(std::ostream&) const’: discontiguous-io.cpp:87:8: warning: ‘auto’ changes meaning in C++11; please remove it [-Wc++0x-compat] for (auto p = m_v.begin(); p != m_v.end(); ++p) ^ discontiguous-io.cpp:87:13: error: ‘p’ does not name a type for (auto p = m_v.begin(); p != m_v.end(); ++p) ^ discontiguous-io.cpp:87:30: error: expected ‘;’ before ‘p’ for (auto p = m_v.begin(); p != m_v.end(); ++p) ^ discontiguous-io.cpp:87:30: error: ‘p’ was not declared in this scope discontiguous-io.cpp: In function ‘void dumphex(std::ostream&, const void*, size_t)’: discontiguous-io.cpp:105:10: error: ‘uintptr_t’ was not declared in this scope << (uintptr_t)a + i << ':'; ^ discontiguous-io.cpp:105:20: error: expected ‘;’ before ‘a’ << (uintptr_t)a + i << ':'; ^ discontiguous-io.cpp:110:22: error: ‘uint8_t’ was not declared in this scope << (unsigned)((uint8_t*)a)[j]; ^ discontiguous-io.cpp:110:30: error: expected primary-expression before ‘)’ token << (unsigned)((uint8_t*)a)[j]; ^ discontiguous-io.cpp:110:31: error: expected ‘)’ before ‘a’ << (unsigned)((uint8_t*)a)[j]; ^ discontiguous-io.cpp:114:24: error: ‘uint8_t’ was not declared in this scope unsigned char c = ((uint8_t*)a)[j]; ^ discontiguous-io.cpp:114:32: error: expected primary-expression before ‘)’ token unsigned char c = ((uint8_t*)a)[j]; ^ discontiguous-io.cpp:114:33: error: expected ‘)’ before ‘a’ unsigned char c = ((uint8_t*)a)[j]; ^ discontiguous-io.cpp: At global scope: discontiguous-io.cpp:101:13: warning: unused parameter ‘a’ [-Wunused-parameter] static void dumphex(std::ostream &os, const void *a, size_t len) ^ discontiguous-io.cpp:126:51: error: ‘uint32_t’ has not been declared static ssize_t sg_read(const file_descriptor &fd, uint32_t lba, ^ discontiguous-io.cpp: In function ‘ssize_t sg_read(const file_descriptor&, int, const iovec_t&)’: discontiguous-io.cpp:143:2: error: ‘uint8_t’ was not declared in this scope uint8_t read6[6] = { ^ discontiguous-io.cpp:143:10: error: expected ‘;’ before ‘read6’ uint8_t read6[6] = { ^ discontiguous-io.cpp:153:11: error: ‘read6’ was not declared in this scope h.cmdp = read6; ^ discontiguous-io.cpp:163:54: error: ‘errno’ was not declared in this scope std::cerr << "READ(6) ioctl failed with errno " << errno ^ discontiguous-io.cpp:167:2: error: ‘uint32_t’ was not declared in this scope uint32_t result = h.status | (h.msg_status << 8) | ^ discontiguous-io.cpp:167:11: error: expected ‘;’ before ‘result’ uint32_t result = h.status | (h.msg_status << 8) | ^ discontiguous-io.cpp:169:6: error: ‘result’ was not declared in this scope if (result) { ^ discontiguous-io.cpp: At global scope: discontiguous-io.cpp:181:52: error: ‘uint32_t’ has not been declared static ssize_t sg_write(const file_descriptor &fd, uint32_t lba, ^ discontiguous-io.cpp: In function ‘ssize_t sg_write(const file_descriptor&, int, const iovec_t&)’: discontiguous-io.cpp:208:9: error: ‘errno’ was not declared in this scope << errno << '\n'; ^ discontiguous-io.cpp:217:2: error: ‘uint8_t’ was not declared in this scope uint8_t write6[6] = { ^ discontiguous-io.cpp:217:10: error: expected ‘;’ before ‘write6’ uint8_t write6[6] = { ^ discontiguous-io.cpp:227:11: error: ‘write6’ was not declared in this scope h.cmdp = write6; ^ discontiguous-io.cpp:237:55: error: ‘errno’ was not declared in this scope std::cerr << "WRITE(6) ioctl failed with errno " << errno ^ discontiguous-io.cpp:241:2: error: ‘uint32_t’ was not declared in this scope uint32_t result = h.status | (h.msg_status << 8) | ^ discontiguous-io.cpp:241:11: error: expected ‘;’ before ‘result’ uint32_t result = h.status | (h.msg_status << 8) | ^ discontiguous-io.cpp:243:6: error: ‘result’ was not declared in this scope if (result) { ^ discontiguous-io.cpp: In function ‘int main(int, char**)’: discontiguous-io.cpp:263:2: error: ‘uint32_t’ was not declared in this scope uint32_t offs = 0; ^ discontiguous-io.cpp:263:11: error: expected ‘;’ before ‘offs’ uint32_t offs = 0; ^ discontiguous-io.cpp:266:14: error: ‘uint8_t’ was not declared in this scope std::vector<uint8_t> buf; ^ discontiguous-io.cpp:266:21: error: template argument 1 is invalid std::vector<uint8_t> buf; ^ discontiguous-io.cpp:266:21: error: template argument 2 is invalid discontiguous-io.cpp:266:26: error: invalid type in declaration before ‘;’ token std::vector<uint8_t> buf; ^ discontiguous-io.cpp:269:48: error: ‘EOF’ was not declared in this scope while ((c = getopt(argc, argv, "hl:o:sw")) != EOF) { ^ discontiguous-io.cpp:271:42: error: ‘strtoul’ was not declared in this scope case 'l': len = strtoul(optarg, NULL, 0); break; ^ discontiguous-io.cpp:272:13: error: ‘offs’ was not declared in this scope case 'o': offs = strtoul(optarg, NULL, 0); break; ^ discontiguous-io.cpp:285:6: error: request for member ‘resize’ in ‘buf’, which is of non-class type ‘int’ buf.resize(len); ^ discontiguous-io.cpp:297:7: error: ‘offs’ was not declared in this scope if (offs % block_size) { ^ discontiguous-io.cpp:303:8: error: request for member ‘resize’ in ‘buf’, which is of non-class type ‘int’ buf.resize(buf.size() * 2); ^ discontiguous-io.cpp:303:19: error: request for member ‘size’ in ‘buf’, which is of non-class type ‘int’ buf.resize(buf.size() * 2); ^ discontiguous-io.cpp:304:29: error: request for member ‘begin’ in ‘buf’, which is of non-class type ‘int’ unsigned char *p = &*buf.begin(); ^ discontiguous-io.cpp:309:21: error: request for member ‘begin’ in ‘buf’, which is of non-class type ‘int’ iov.append(&*buf.begin(), buf.size()); ^ discontiguous-io.cpp:309:34: error: request for member ‘size’ in ‘buf’, which is of non-class type ‘int’ iov.append(&*buf.begin(), buf.size()); ^ discontiguous-io.cpp:322:31: error: ‘offs’ was not declared in this scope ssize_t len = sg_write(fd, offs / block_size, iov); ^ discontiguous-io.cpp:328:30: error: ‘offs’ was not declared in this scope ssize_t len = sg_read(fd, offs / block_size, iov); ^ make[1]: *** [discontiguous-io] Error 1 make[1]: Leaving directory /mnt/tests/kernel/storage/SSD/nvme_blktest/blktests/src'
make: *** [all] Error 2

block/005 takes too long with network device

I have run block/005 test with a device over Infiniband.
block/005 executes random read 1G that takes more than 30 minutes.

I think it would be better to read less for the network device.

scsi/004 question

I didn't see this path /proc/scsi/scsi_debug/
Is it deprecated ?

tests/loop/006 losetup option question

just misunderstand... igore this :)

nbd/001 failed

kernel version: 4.17.0-rc5

nbd/001 (resize a connected nbd device) [failed]
runtime ... 0.675s
— tests/nbd/001.out 2018-05-14 14:08:43.000000000 +0800
+++ results/nodev/nbd/001.out.bad 2018-05-15 10:03:20.662553981 +0800
@@ -2,5 +2,6 @@
Disk /dev/nbd0: 10.7GB
nbd0 43:0 0 10G 0 disk
Setting size to 1gib
-nbd0 43:0 0 1G 0 disk
-Disk /dev/nbd0: 1074MB
+NBD_SET_SIZE: Invalid argument
+nbd0 43:0 0 10G 0 disk
...
(Run 'diff -u tests/nbd/001.out results/nodev/nbd/001.out.bad' to see the entire diff)

001.out.bad

Running nbd/001
Disk /dev/nbd0: 10.7GB
nbd0  43:0    0  10G  0 disk
Setting size to 1gib
NBD_SET_SIZE: Invalid argument
nbd0  43:0    0  10G  0 disk
Disk /dev/nbd0: 10.7GB

blktests nbd/001 failed due to the output of 'lsblk -n /dev/nbd0'

uname -r

6.8.0-rc3+

lsblk --version

lsblk from util-linux 2.40-rc1

./check nbd/001

nbd/001 (resize a connected nbd device) [failed]
runtime 0.027s ... 0.423s
--- tests/nbd/001.out 2024-02-18 06:47:36.303147966 -0500
+++ /mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/nbd/001.out.bad 2024-02-18 11:20:58.775548133 -0500
@@ -1,6 +1,6 @@
Running nbd/001
Disk /dev/nbd0: 10.7GB
-nbd0 43:0 0 10G 0 disk
+nbd0 43:0 0 10G 0 disk
Setting size to 1gib
-nbd0 43:0 0 1G 0 disk
+nbd0 43:0 0 1G 0 disk
...
(Run 'diff -u tests/nbd/001.out /mnt/tests/gitlab.com/api/v4/projects/19168116/repository/archive.zip/storage/blktests/blk/blktests/results/nodev/nbd/001.out.bad' to see the entire diff)

block/018 question

The block/018 use the same read command twice again.
dd if=/dev/nullb0 of=/dev/null bs=4096 iflag=direct count=1 status=none &
dd if=/dev/zero of=/dev/nullb0 bs=4096 oflag=direct count=1 status=none &
dd if=/dev/zero of=/dev/nullb0 bs=4096 oflag=direct count=1 status=none &
Is it for any special purpose ?

block/009 failed

Hi,

The block/009 test case failed as below.
I tested it on two machines and both resulted the same failure.

I tried with xfsprogs 4.9.0 on Ubuntu and xfsprogs 4.16.0-rc1 on Debian but failed
I tried "noop" and "deadline" IO scheduler but failed

gohkim@ws00837:~/work/tools/blktests$ sudo ./check block/009
block/009 (check page-cache coherency after BLKDISCARD)      [failed]
    runtime  ...  0,977s
    --- tests/block/009.out	2018-04-23 17:52:00.222822301 +0200
    +++ results/nodev/block/009.out.bad	2018-04-23 17:54:34.571254091 +0200
    @@ -1,8 +1,17 @@
     Running block/009
     0000000 0000 0000 0000 0000 0000 0000 0000 0000
     *
    +0200000 bbbb bbbb bbbb bbbb bbbb bbbb bbbb bbbb
    +*
    +0c00000 0000 0000 0000 0000 0000 0000 0000 0000
    +*
    ...
    (Run 'diff -u tests/block/009.out results/nodev/block/009.out.bad' to see the entire diff)
gohkim@ws00837:~/work/tools/blktests$ cat results/nodev/block/009.out.bad 
Running block/009
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0200000 bbbb bbbb bbbb bbbb bbbb bbbb bbbb bbbb
*
0c00000 0000 0000 0000 0000 0000 0000 0000 0000
*
2000000
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0200000 bbbb bbbb bbbb bbbb bbbb bbbb bbbb bbbb
*
0c00000 0000 0000 0000 0000 0000 0000 0000 0000
*
2000000
modprobe: FATAL: Module scsi_debug is in use.
Test complete

If I ran blkdiscard after the test, the sdg device was cleared.

root@ib1:/home/gkim/pb-ltp/blktests# ./check block/009
block/009 (check page-cache coherency after BLKDISCARD)      [failed]
    runtime  2.334s  ...  2.380s
    --- tests/block/009.out	2018-04-23 14:21:33.011890789 +0200
    +++ results/nodev/block/009.out.bad	2018-04-23 18:07:12.451914680 +0200
    @@ -1,8 +1,17 @@
     Running block/009
     0000000 0000 0000 0000 0000 0000 0000 0000 0000
     *
    +0200000 bbbb bbbb bbbb bbbb bbbb bbbb bbbb bbbb
    +*
    +0c00000 0000 0000 0000 0000 0000 0000 0000 0000
    +*
    ...
    (Run 'diff -u tests/block/009.out results/nodev/block/009.out.bad' to see the entire diff)
root@ib1:/home/gkim/pb-ltp/blktests# blkdiscard /dev/sdg
root@ib1:/home/gkim/pb-ltp/blktests# dd if=/dev/sdg bs=4M iflag=direct | hexdump
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
8+0 records in
8+0 records out
33554432 bytes (34 MB) copied, 0.122978 s, 273 MB/s
2000000

I hope you could guess the reason.
Please inform me if you need more information.

block/003 doesn't honor multiple test devices

Test block/0003 doesn't honor multiple test devices:

# cat config 
TEST_DEVS=(/dev/nvme0n1 /dev/zram0)
# ./check block/003
block/003 => nvme0n1 (run various discard sizes)             [not run]
    /dev/nvme0n1 does not support discard

Other tests like block/004 do:

# ./check block/004 
block/004 => nvme0n1 (run lots of flushes)
    runtime  31.522s  ...
block/004 => nvme0n1 (run lots of flushes)                   [passed]
    runtime     31.522s  ...  31.115s 
    write iops           ...  531
block/004 => zram0 (run lots of flushes)
block/004 => zram0 (run lots of flushes)                     [passed]
    runtime     0.658s  ...  0.582s
    write iops  54613   ...  63015004 at 2017-05-19 11:06:54

scsi_debug module is not available

the scsi_debug module cannot be tested on the fedora,
the error message "scsi_debug module is not available" appears,

# ./check block
block/001 (stress device hotplugging)                        [not run]
    scsi_debug module is not available
block/002 (remove a device while running blktrace)           [not run]
    scsi_debug module is not available

it is caused by https://github.com/osandov/blktests/blob/master/common/rc line 33 and 34,

_module_file_exists()
{
	local ko_underscore=${1//-/_}.ko
	local ko_hyphen=${1//_/-}.ko

on fedora, modules end with .ko.xz,I hope these two lines can be modified to be compatible with the module naming format of different platforms

Thanks,

block 012 set read only twice

test_device() {
	echo "Running ${TEST_NAME}"

	blockdev --getro "$TEST_DEV"
	xfs_io -c "pwrite -w -S 0xaa -b 2M 0 2M" -d "$TEST_DEV" >>"$FULL"
	dd if="$TEST_DEV" bs=2M count=1 2>>"$FULL" | hexdump
	blockdev --setro "$TEST_DEV"
	blockdev --setro "$TEST_DEV"
	blockdev --getro "$TEST_DEV"

In block/012, blockdev --setro "$TEST_DEV" is executed twice. Is it for special purpose ?

loop/009 fails with unrecognized option '--ping'

The loop/009 test fails on older versions of systemd (prior to 241) because the new option --ping does not exist.

Reading through the announcement for systemd 241, we see mention of the new ping option there:
https://lists.freedesktop.org/archives/systemd-devel/2019-February/042169.html

udevadm control learnt a new option for --ping for testing whether a
systemd-udevd instance is running and reacting

udevadm -V
239 (239-78.el8)

./check loop/009
loop/009 (check that LOOP_CONFIGURE sends uevents for partitions) [failed]
runtime 0.460s ... 0.481s
--- tests/loop/009.out 2023-11-27 05:09:08.000000000 -0600
+++ /root/blktests-master/results/nodev/loop/009.out.bad 2023-11-28 07:09:35.959089187 -0600
@@ -1,3 +1,4 @@
Running loop/009
+control: unrecognized option '--ping'
KERNEL add /devices/virtual/block/loop_/loop_p1 (block)
Test complete

udevadm control --ping
control: unrecognized option '--ping'

Some tests fail with "'device' is not a PCI device"

I was trying to run the batch of tests, and noticed that some tests fail with `device is not a PCI device':

[root@g-prime blktests]# cat config 
TEST_DEVS=(/dev/nvme2n1)
[root@g-prime blktests]# ./check  -d
cat: /sys/block/nvme2c33n1/dev: No such file or directory
[snip]
block/011 => nvme2n1 (disable PCI device while doing I/O)    [not run]
    /dev/nvme2n1 is not a PCI device

Looking a bit, I tried to find the logic that decides whether the device is a PCI device or not:

[root@g-prime blktests]# source check
^C
[root@g-prime blktests]# readlink -f $(_find_sysfs_dir /dev/nvme2n1)
cat: /sys/block/nvme2c33n1/dev: No such file or directory
/sys/devices/virtual/nvme-subsystem/nvme-subsys2/nvme2n1
[root@g-prime blktests]# readlink -f $(_find_sysfs_dir /dev/nvme2)
/sys/devices/pci0000:ae/0000:ae:00.0/0000:af:00.0/0000:b0:04.0/0000:b1:00.0/nvme/nvme2/nvme1n1

Okay, the /dev/nvme2 node eventually traces back to a PCI device. Maybe I need to use this one, but this is also not accepted by the framework:

[root@g-prime blktests]# cat config 
TEST_DEVS=(/dev/nvme2)
[root@g-prime blktests]# ./check  -d
./check: /dev/nvme2 is not a block device

I suspect I'm either using this completely wrong, or something else is broken along the way.

src/miniublk.c does not link on Debian

On Debian bookwork with liburing-dev installed, I cannot link miniublk:

root@9a184f27ad81:/blktests# make
make -C src all
make[1]: Entering directory '/blktests/src'
cc -O2 -Wall -Wshadow  -DHAVE_LINUX_BLKZONED_H  -D_GNU_SOURCE -lpthread -luring -o miniublk miniublk.c
/usr/bin/ld: /tmp/ccCgk2hG.o: in function `ublk_ctrl_init':
miniublk.c:(.text+0xaeb): undefined reference to `io_uring_queue_init_params'
/usr/bin/ld: /tmp/ccCgk2hG.o: in function `ublk_queue_deinit':
miniublk.c:(.text+0xb73): undefined reference to `io_uring_unregister_ring_fd'
/usr/bin/ld: miniublk.c:(.text+0xb85): undefined reference to `io_uring_unregister_files'
/usr/bin/ld: /tmp/ccCgk2hG.o: in function `ublk_io_handler_fn':
miniublk.c:(.text+0xd62): undefined reference to `io_uring_queue_init_params'
/usr/bin/ld: miniublk.c:(.text+0xd77): undefined reference to `io_uring_register_ring_fd'
/usr/bin/ld: miniublk.c:(.text+0xd8c): undefined reference to `io_uring_register_files'
/usr/bin/ld: miniublk.c:(.text+0xe94): undefined reference to `io_uring_submit_and_wait_timeout'
/usr/bin/ld: /tmp/ccCgk2hG.o: in function `__ublk_ctrl_cmd':
miniublk.c:(.text+0x14a6): undefined reference to `io_uring_submit'
/usr/bin/ld: miniublk.c:(.text+0x1533): undefined reference to `__io_uring_get_cqe'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:61: miniublk] Error 1
make[1]: Leaving directory '/blktests/src'
make: *** [Makefile:5: all] Error 2

However, if i apply this trivial patch, it does link.

diff --git a/src/Makefile b/src/Makefile
index 1365480..8f52bbc 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -39,7 +39,7 @@ CONFIG_DEFS := $(call HAVE_C_HEADER,linux/blkzoned.h,-DHAVE_LINUX_BLKZONED_H)
 override CFLAGS   := -O2 -Wall -Wshadow $(CFLAGS) $(CONFIG_DEFS)
 override CXXFLAGS := -O2 -std=c++11 -Wall -Wextra -Wshadow -Wno-sign-compare \
                     -Werror $(CXXFLAGS) $(CONFIG_DEFS)
-MINIUBLK_FLAGS :=  -D_GNU_SOURCE -lpthread -luring
+MINIUBLK_FLAGS :=  -D_GNU_SOURCE -lpthread
 LDFLAGS ?=
 
 all: $(TARGETS)
@@ -58,6 +58,6 @@ $(CXX_TARGETS): %: %.cpp
        $(CXX) $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) -o $@ $^
 
 $(C_MINIUBLK): %: miniublk.c
-       $(CC) $(CFLAGS) $(LDFLAGS) $(MINIUBLK_FLAGS) -o $@ miniublk.c
+       $(CC) $(CFLAGS) $(LDFLAGS) $(MINIUBLK_FLAGS) -o $@ miniublk.c -luring
 
 .PHONY: all clean install

I am aware that -l position on the command line may impact linkage in some cases, but I have absolutely no idea why it matters here.

This can be reproduced easily with a debian:bookworm docker container:

$ docker run -it debian:bookworm
root@9a184f27ad81:/# apt-get update && apt-get -y install build-essential git liburing-dev
root@9a184f27ad81:/# git clone https://github.com/osandov/blktests.git && cd blktests && make

block/005 fail

I found kernel 5.10 cannot pass the block/005 case.
Does anyone observe this issue ?

Expected behavior of "block/011 (disable PCI device while doing I/O)"

I'm not sure what the pass/fail criteria is or should be for this test. Since this test disables the pci device are we expecting that:

PCI device is periodically re-enabled, transaction resubmitted, and everyone is happy.
PCI device is disabled, transaction times out and device is removed
Nothing happens

What I am observing is that the nvme driver correvtly identifies transactions as timing out, and removes the device:

nvme nvme0: I/O 14 QID 0 timeout, disable controller
nvme nvme0: Identify Controller failed (-4)
nvme nvme0: Removing after probe failure status: -5

However, once the device is removed, the test fails:

+fio: ioengines.c:289: td_io_queue: Assertion `(io_u->flags & IO_U_F_FLIGHT) == 0' failed.
+fio: ioengines.c:289: td_io_queue: Assertion `(io_u->flags & IO_U_F_FLIGHT) == 0' failed.
+fio: ioengines.c:289: td_io_queue: Assertion `(io_u->flags & IO_U_F_FLIGHT) == 0' failed.

So, what are we testing for here?

block/009 verify cache dropped

Hi,

In this case, there're two xfs_io write command and two hexdump.
Why don't we only use one time xfs_io and hexdump ?

Support setting config options as environment variables

Running check with -d option doesn't work for me. I would have expected that -d takes a list of devices rather than reading some environment variable. Hoewever, even setting TEST_DEVS doesn't seem to work:

[root@g-prime blktests]# TEST_DEVS=/dev/nvme0n1 ./check -d
./check: DEVICE_ONLY specified without TEST_DEVS

Or:

[root@g-prime blktests]# TEST_DEVS=(/dev/nvme0n1) ./check -d
./check: DEVICE_ONLY specified without TEST_DEVS

Or:

[root@g-prime blktests]# sh
sh-4.4# TEST_DEVS=(/dev/nvme0n1 /dev/sdb)
sh-4.4# ./check -d
./check: DEVICE_ONLY specified without TEST_DEVS
sh-4.4# TEST_DEVS=(/dev/nvme0n1 /dev/sdb) ./check -d
./check: DEVICE_ONLY specified without TEST_DEVS

nvme/007 (create an NVMeOF target with a file-backed ns) [failed]

hi, when i run nvme/007, it always failed, anybody hits the same error?

nvme/007 (create an NVMeOF target with a file-backed ns) [failed]
runtime ... 0.082s
--- tests/nvme/007.out 2018-08-01 03:52:38.108707079 +0000
+++ /lkp/benchmarks/blktests/blktests/results/nodev/nvme/007.out.bad 2018-08-01 03:53:19.650709135 +0000
@@ -1,2 +1,3 @@
Running nvme/007
+tests/nvme/rc: line 76: printf: write error: Invalid argument
Test complete

here is my kernel version and fio version

root@lkp-hsw-ep4 ~# uname -a
Linux lkp-hsw-ep4 4.18.0-rc7 #1 SMP Wed Aug 1 13:14:37 CST 2018 x86_64 GNU/Linux
root@lkp-hsw-ep4 ~# fio --version
fio-2.16

my test machine infomation

model: Haswell-EP
nr_node: 2
nr_cpu: 72
memory: 128G
nr_ssd_partitions: 1
ssd_partitions: /dev/nvme0n1p1
swap_partitions:
rootfs_partition:
brand: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz

block/009 is unstable

OS: qemu + virtio_scsi + debian 9 + v4.19-rc7

root@vm-kbuild-8G-7 /lkp/benchmarks/blktests# for i in $(seq 1 100); do ./check block/009 ; sleep 3; done
block/009 (check page-cache coherency after BLKDISCARD)      [passed]
    runtime  1.127s  ...  0.931s
block/009 (check page-cache coherency after BLKDISCARD)      [passed]
    runtime  0.931s  ...  1.109s
block/009 (check page-cache coherency after BLKDISCARD)      [failed]
    runtime  1.109s  ...  1.168s
    --- tests/block/009.out	2018-08-01 11:13:07.000000000 +0000
    +++ /lkp/benchmarks/blktests/results/nodev/block/009.out.bad	2018-10-17 16:36:18.881000000 +0000
    @@ -1,6 +1,8 @@
     Running block/009
     0000000 0000 0000 0000 0000 0000 0000 0000 0000
     *
    +1fffe00 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
    +*
     2000000
     0000000 0000 0000 0000 0000 0000 0000 0000 0000
    ...
    (Run 'diff -u tests/block/009.out /lkp/benchmarks/blktests/results/nodev/block/009.out.bad' to see the entire diff)
block/009 (check page-cache coherency after BLKDISCARD)      [failed]
    runtime  1.168s  ...  0.959s
    --- tests/block/009.out	2018-08-01 11:13:07.000000000 +0000
    +++ /lkp/benchmarks/blktests/results/nodev/block/009.out.bad	2018-10-17 16:36:23.028000000 +0000
  
  @@ -1,6 +1,10 @@
     Running block/009
     0000000 0000 0000 0000 0000 0000 0000 0000 0000
     *
    +1fb6000 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
    +*
    +1fb7000 0000 0000 0000 0000 0000 0000 0000 0000
    +*
    ...
    (Run 'diff -u tests/block/009.out /lkp/benchmarks/blktests/results/nodev/block/009.out.bad' to see the entire diff)
block/009 (check page-cache coherency after BLKDISCARD)      [passed]
    runtime  0.959s  ...  1.250s
block/009 (check page-cache coherency after BLKDISCARD)      [passed]
    runtime  1.250s  ...  0.701s
block/009 (check page-cache coherency after BLKDISCARD)      [passed]
    runtime  0.701s  ...  1.280s
block/009 (check page-cache coherency after BLKDISCARD)      [passed]
    runtime  1.280s  ...  0.907s
block/009 (check page-cache coherency after BLKDISCARD)      [passed]
    runtime  0.907s  ...  0.723s
block/009 (check page-cache coherency after BLKDISCARD)      [passed]
    runtime  0.723s  ...  1.070s
block/009 (check page-cache coherency after BLKDISCARD)      [passed]

nvme: fc: add a test case to check module unload before fc resource cleanup

As discussed in mailing lists, test cases in nvme group fail for nvme_trtype=fc, when relevant modules are unloaded before fc resource cleanup: ref

It is desired to add a test case to trigger the failure, so that the failure gets fixed and prevented.

_have_cpu_hotplug lost the latest cpu

In that function, if cpu0-4/online is writable, the ALL_CPUS only includes cpu0-3.
Is it intentional?

loop0 loop1 loop2 still exists after loop/006

Hello
After loop/006, the /dev/loop0 /dev/loop1 /dev/loop2 still exists and cannot be removed by losetup -d, but can be removed after the loop module remove, not sure if it's one tests issue or kernel issue?

# ./check loop/006
loop/006 (change loop backing file while creating/removing another loop device) [passed]
    runtime    ...  31.201s
# ll /dev/loop*
crw-rw----. 1 root disk 10, 237 Oct 17 08:02 /dev/loop-control
brw-rw----. 1 root disk  7,   0 Oct 17 08:03 /dev/loop0
brw-rw----. 1 root disk  7,   1 Oct 17 08:03 /dev/loop1
brw-rw----. 1 root disk  7,   2 Oct 17 08:03 /dev/loop2

# losetup -d /dev/loop0
losetup: /dev/loop0: detach failed: No such device or address

# losetup -d /dev/loop1
losetup: /dev/loop1: detach failed: No such device or address

# losetup -d /dev/loop2
losetup: /dev/loop2: detach failed: No such device or address

# rmmod loop

# ll /dev/loop*
crw-rw----. 1 root disk 10, 237 Oct 17 08:04 /dev/loop-control

what's the fail case of block/016

I see the git log shows it's a regression test. If I commit a wrong patch causing the regression fail.
What's the fail symptom or log ?
I found the script only check the output message and exit value.

block/008 fails with "+_fio_perf: too many terse lines"

Not sure if PEBKAC or incompatibility with linux-4.18-rc3

I'm having a bit of difficulty following where the "clock setaffinity failed" message originates.

block/008 => nvme2n1 (do IO while hotplugging CPUs)          [failed]
    runtime  39.688s  ...  38.372s
    --- tests/block/008.out     2018-07-06 14:58:35.013250320 -0500
    +++ results/nvme2n1/block/008.out.bad       2018-07-06 15:14:22.495426191 -0500
    @@ -1,2 +1,4 @@
     Running block/008
    +clock setaffinity failed: Invalid argument
    +_fio_perf: too many terse lines
     Test complete

The contents of "$TMPDIR/fio_perf" are:

clock setaffinity failed: Invalid argument
4;fio-3.3;reads;0;0;67108864;1785570;446392;37584;0;0;0.000000;0.000000;63;117276;137.643766;222.195713;1.000000%=78;5.000000%=84;10.000000%=87;20.000000%=93;30.000000%=99;40.000000%=104;50.000000%=114;60.000000%=127;70.000000%=144;80.000000%=166;90.000000%=205;95.000000%=246;99.000000%=350;99.500000%=415;99.900000%=774;99.950000%=1433;99.990000%=7897;0%=0;0%=0;0%=0;63;117276;138.572067;222.363517;5955;36714;1.577175%;28161.562064;2837.846236;0;0;0;0;0;0;0.000000;0.000000;0;0;0.000000;0.000000;1.000000%=0;5.000000%=0;10.000000%=0;20.000000%=0;30.000000%=0;40.000000%=0;50.000000%=0;60.000000%=0;70.000000%=0;80.000000%=0;90.000000%=0;95.000000%=0;99.000000%=0;99.500000%=0;99.900000%=0;99.950000%=0;99.990000%=0;0%=0;0%=0;0%=0;0;0;0.000000;0.000000;0;0;0.000000%;0.000000;0.000000;0;0;0;0;0;0;0.000000;0.000000;0;0;0.000000;0.000000;1.000000%=0;5.000000%=0;10.000000%=0;20.000000%=0;30.000000%=0;40.000000%=0;50.000000%=0;60.000000%=0;70.000000%=0;80.000000%=0;90.000000%=0;95.000000%=0;99.000000%=0;99.500000%=0;99.900000%=0;99.950000%=0;99.990000%=0;0%=0;0%=0;0%=0;0;0;0.000000;0.000000;0;0;0.000000%;0.000000;0.000000;2.428582%;5.466262%;16823913;0;791;100.0%;0.0%;0.0%;0.0%;0.0%;0.0%;0.0%;0.00%;0.00%;0.00%;0.00%;0.00%;31.09%;64.14%;4.49%;0.18%;0.03%;0.04%;0.01%;0.03%;0.01%;0.01%;0.00%;0.01%;0.00%;0.00%;0.00%;0.00%;0.00%;nvme2n1;0;0;0;0;0;0;0;0.00%

osandov / blktests Goto Github PK

blktests's People

Contributors

Stargazers

Watchers

Forkers

blktests's Issues

uname -r

lspci | grep -i non

readlink -f /sys/block/nvme0n1/device | grep -Eo '[0-9a-f]{4}:[0-9a-f]{2}:[0-9a-f]{2}.[0-9a-f]'

./check tests/srp/001

cat /home/blktests/results/nodev/srp/001.out.bad

uname -r

lsblk --version

./check nbd/001

Recommend Projects

Recommend Topics

Recommend Org