[PATCH 0/9] xfs: metadata CRCs, kernel, first batch

[Ben Myers]

Hi Dave,

On Sat, Feb 23, 2013 at 01:38:18PM +1100, Dave Chinner wrote:
> On Fri, Feb 22, 2013 at 05:50:29PM -0600, Ben Myers wrote:
> > On Sat, Feb 23, 2013 at 10:12:17AM +1100, Dave Chinner wrote:
> > > On Fri, Feb 22, 2013 at 09:19:31AM -0600, Ben Myers wrote:
> > > This is mentioned in the patch zero description:
> > > 
> > > "This series makes is through to 001-092 in xfstests - there is a
> > > problem in the dquot verifier that causes log recovery of dquot
> > > buffers to follow a NULL pointer."
> > >
> > > Basically, mp->m_quotainfo is not initialised until after log
> > > recovery occurs, so this has to be detected in the verify/crc
> > > routines otherwise it goes splat like above. My current patch series
> > > has this fixed.
> > 
> > Cool.  Sorry for the extra noise.
> 
> No, that's fine. It tells me that you're actaully looking at the
> code and seeing what it does ;)
> 
> I'm close to having a new version of the kernel patchset out. I've
> just got to finish debugging the attribute changes I've made and
> move the superblock support patch to the end of the series and I'll
> post it out.
> 
> All I'm aiming for with the next version of the patch set is that
> existing filesystems (i.e. no CRCs) are regression free. I've
> actaully done very little CRC enabled testing while doing all the
> directory and attribute code changes, mainly because I can't test
> them properly until the userspace support is there. However, the
> patch set up to the final patch (i.e. everything but the attribute
> changes) seems to work just fine with the existing toolchain and
> xfstests.
> 
> Put simply, my focus for testing the patch set is currently "no
> regressions for existing users", not "CRCs work perfectly".

Sounds good.  I'll keep that in mind.

-Ben