[Top] [All Lists]

Re: [PATCH 3/3] xfs: ensure btree root split sets blkno correctly

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 3/3] xfs: ensure btree root split sets blkno correctly
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 14 Jun 2013 10:21:22 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130613191617.GY20932@xxxxxxx>
References: <1371003548-4026-1-git-send-email-david@xxxxxxxxxxxxx> <1371003548-4026-4-git-send-email-david@xxxxxxxxxxxxx> <20130613191617.GY20932@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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
telling us...

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
doesn't cover.

> I
> 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.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>