A few comments on the test (explained in the git commit log):
----
[PATCH] canonical: convert ndctl/test into qa-regression-ndctl tests
## good tests (bad results mean something)
blk-exhaust.sh
btt-check.sh
btt-pad-compat.sh
label-compat.sh
multi-dax.sh
rescan-partitions.sh
sector-mode.sh
dax-ext4.sh
dax-xfs.sh
## TODO: needs more work. locking/unlocking nvdimms using keyutils
security.sh
## TODO: do a merge proposal to debian fio pkg enabling pmem engines
device-dax-fio.sh
## TODO: enable this tests by compiling "test/" directory (next phase)
mmap.sh
monitor.sh
## alignment issues (full ns boundaries not aligned, TODO: smaller ns
might work)
create.sh
## needs injection (error or smart) and qemu nvdimm emulation does not
support it
btt-errors.sh
clear.sh
daxdev-errors.sh
inject-error.sh
inject-smart.sh
pfn-meta-errors.sh
pmem-errors.sh
## qemu nvdimm is pmem_compat (dax-class instead of dax-mode)
daxctl-devices.sh
## Expected output:
~/ndctl/test$ ./regression.sh
test ./blk-exhaust.sh: succeeded
test ./btt-check.sh: succeeded
test ./btt-pad-compat.sh: succeeded
test ./label-compat.sh: succeeded
test ./multi-dax.sh: succeeded
test ./rescan-partitions.sh: succeeded
test ./sector-mode.sh: succeeded
test ./dax-ext4.sh: succeeded
test ./dax-xfs.sh: succeeded
## Expected return code:
0 = All tests have succeeded
1 = A test has failed (check /tmp/regression.log)
Signed-off-by: Rafael David Tinoco <rafaeldtin...@ubuntu.com>
----
# security team
Please note that, security wise, you're probably interested in the
security.sh test. It uses keys to lock/unlock nvdimm devices (an
interesting feature for 20.04 I suppose). I'm not entirely sure the
emulated nvdimms will be enough for this test to run BUT I can help you
after all this has been placed somewhere and is up and running.
# other todos:
i might be able to fix the TODOs here but I'm trying to be careful on
how much time Im spending on this (balancing with other things for
20.04).
@Christian:
Do you think this patch could be put as a delta for ndctl/test directory
? I'm thinking in supportability in the next years to come. Keeping it
out of the source package might make it hard to either extend it and/or
fix changes.
Note: ndctl/test is not used for anything in binary packages, it would
just be in the source packages. I could even add those as debian/tests
for autopkgtest, and skip tests if being ran in a machine that doesn't
support nvdimms (even suggesting to Debian).
Thoughts ?
PS: I'm pretty sure with those tests we're able to maintain this and
catch regressions regarding PMEM-based block devices being accessed with
DAX and/or through MMAPs (having the mmap tests fixed would be also
beneficial).
For now I'm considering this done, missing only a place to merge this.
Thank you!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1853506
Title:
[MIR] ndctl
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
