On 1/10/24 09:12, Chaitanya Kulkarni wrote:
Should this be TEST_DEV instead ?
why ?
My understanding of blktests is, add device which we want to test in
config files under TEST_DEV (except null-blk and nvme-fabrics loopback
devices, which are usually populated inside the tests).
In this case, if someone do not want to disturb nvme0n1 device,
this test doesn't allow it.
Regards,
Nitesh Shetty
it is clearly stated in the documentation that blktests are destructive
to the entire system and including any devices you have, if your
system has sensitive data then _don't run these tests_ simple, when
you are running blktests you are bound to disturb system you can't
prevent that by using TEST_DEV.
I don't think this is the direction we want to go.
NVMe for internal drives is becoming more and more prevalent (especially
on laptops), making them unusable for running blktests.
We have been putting quite some effort into nvme-cli to ensure that
blktest _can_ run concurrently with other NVMe drives, so really we
should not hard-code any device names.
Or we discuss this at LSF/MM; Daniel or me will be happy to give an
overview about concurrent NVMe-oF management applications on the same
system (nvme-cli, nvme-stas, blktests all running at the same time).
Cheers,
Hannes
