On 1/10/2024 1:24 AM, Hannes Reinecke wrote: > 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. > Okay ... > 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). > would be a great topic for the blktests session ... > Cheers, > > Hannes > I'll make it TEST_DEV change ... -ck
