Re: [PATCH 00/19] xfs: buffer read verifier infrastructure

Dave Chinner
2012-10-11T21:41:11Z

On Thu, Oct 11, 2012 at 07:09:03AM -0500, Mark Tinguely wrote:
> On 10/08/12 22:50, Dave Chinner wrote:
> >Hi folks,
> >
> >This is the next step along the road to metadata CRC checking. What
> >the series does is add an iodone callback to most metadata buffer
> >read operations that is only executed when the buffer is physically
> >read from disk. Read operations that hit the cache do no trigger a
> >verification, as CRCs only protect the on-disk metadata and the
> >in-memory buffer can be changed at any time after it is read without
> >recalculating the CRC of the buffer.
.....
> >Comments, flames and rants about how to do this better are welcome :)
>
> "Don't shoot me, I am only the piano player" -Joe Walsh
>
> I put in the series on top of the previous worker mover series.
> I know this is sketchy in details. I get one of the below on xfstest
> 076:
>
> 1) XFS: Assertion failed: atomic_read(&bp->b_hold) > 0
> from [PATCH 02/14] xfs: rationalise xfs_mount_wq users

I doubt that is related - the patch series does not touch the bufer
locking or reference counting at all, and we know that there is an
existing problem w.r.t. shutdowns and buffer reference counting, so
that's a more likely cause...

> 2) filesystem hang. One process is in inode reclaim waiting on
> the superblock buffer lock, and the umount doing the same.

What's inode reclaim doing trying to get the superblock buffer?
A stack trace might help explain that...

But, again, I doubt that has anything to do with this patch series,
because it does not change the way buffers are accessed/used by
reclaim or unmount.

As it is, I have a v2 just about ready to go - there's quite a few
fixes and additional functionality added to the series....

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com