[Lustre-discuss] [Discuss] coverage measurement at 2012 09 15
andreas.dilger at intel.com
Sat Sep 29 05:24:22 PDT 2012
The coverage data is interesting. It would be even more useful to be able to compare it to the previous code coverage run, if they used the same method for measuring coverage (the new report states that the method has changed and reduced coverage).
Are the percentages if code coverage getting better or worse? Are there particular areas of the code that have poor coverage that could benefit from some focussed attention with new tests?
I can definitely imagine that many error handling code paths (e.g. checking for allocation failures) would not be exercised without specific changes (see e.g. my unlanded patch to fix the OBD_ALLOC() failure injection code).
Running a test with periodic random allication failures enabled and fixing the resulting bugs would improve coverage, though not in a systematic way that could be measured/repeated. Still, this would find a class if hard-to-find bugs.
Similarly, running racer for extended periods is a good form of coverage generation, even if not systematic/repeatable. I think the racer code could be improved/extended by adding racet scripts that are Lustre-specific or exercise new functionality (e.g. "lfs setstripe", setfattr, getfattr, setfacl, getfacl). Running multiple racer instances on multiple clients/mounts and throwing recovery into the mix would definitely find new bugs.
In general, having the code coverage is a good starting point, but it isn't necessarily useful if nothing is done to improve the coverage of the tests as a result.
On 2012-09-20, at 7:21, Roman Grigoryev <Roman_Grigoryev at xyratex.com> wrote:
> next coverage measurement published,
> please see
> Entrance page http://www.opensfs.org/foswiki/bin/view/Lustre/CodeCoverage
> discuss mailing list
> discuss at lists.opensfs.org
More information about the lustre-discuss