Re: [LSF/MM TOPIC] improving storage testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We deliberately check the generation counter to make sure discovery
code path is working as expected. The other text match is hardcoded
as per the cli, I sent out the tentative fixes so we can move forward.


I'll send another series to get rid of the all possible text based
comparisons so that we can avoid this scenario.

On 2/15/19 9:32 AM, Keith Busch wrote:
> On Thu, Feb 14, 2019 at 10:02:02PM -0500, Theodore Y. Ts'o wrote:
>>> My (undocumented) rule of thumb has been that blktests shouldn't assume
>>> anything newer than whatever ships on Debian oldstable. I can document
>>> that requirement.
>>
>> That's definitely not true for the nvme tests; the nvme-cli from
>> Debian stable is *not* sufficient.  This is why I've started building
>> nvme-cli as part of the test appliance in xfstests-bld.  I'm now
>> somewhat suspicious that there are problems because using the latest
>> HEAD of the nvme-cli git tree may have had messages printed to
>> standard out that is subtly different from the version of nvme-cli
>> that was used to develop some of the nvme tests.
> 
> It does appear some expected output has hard coded values that are not
> fixed. Some of the failures are assuming an auto-incrementing generation
> number will always be 1, but that should just be a wildcard match.
> 





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux