On Thu, Jun 13, 2013 at 02:16:17PM -0500, Ben Myers wrote:
> On Wed, Jun 12, 2013 at 12:19:08PM +1000, Dave Chinner wrote:
> > Turns out that on a 1k filesystem, generic/234 accounts for one of
> > those two root splits, and that is somewhat of a smoking gun. In
> > fact, it's the same problem we saw in the directory/attr code where
> > headers are memcpy()d from one block to another without updating the
> > self describing metadata.
> It is very interesting that this area of code is exercised so infrequently.
Well known problem - I remember that we did xfstests code coverage
analysis way back in 2005 at SGI, and this was something that popped
out. The stats simple confirmed what the code coverage profiling was
That's the reason I run 512 byte/1k block size testing all the time
with xfstests - it covers all of these code paths that 4k block size
> remember seeing a paper that described a tool that would list codepaths that
> are exercised during a test run. Does that ring a bell? It seems like this
> might be worth looking into more generally.
You mean code coverage profiling?
FWIW, RH QA has run some xfstests code coverage analysis recently,
too, and it has mostly confirmed the same results that we got at SGI
years ago - we get roughly 70% code coverage of the kernel code
froma default 4k filesystem xfstests run.