Re: [RFC, PATCH 0/6] xfs: delalloc, DIO and corruption....

[Dave Chinner <david@fromorbit.com>]

On Mon, Mar 31, 2014 at 01:22:43PM -0400, Brian Foster wrote:
> On Fri, Mar 21, 2014 at 09:11:44PM +1100, Dave Chinner wrote:
> > Hi folks,
> > 
> > This patch series mostly shuts a can of worms that Al opened when he
> > found the cause of the generic/263 fsx failures. The fix for that is
> > patch 6 of this series, but, well, there are a bunch of other
> > problems that need to be fixed before making that change.
> > 
> > Basically, the direct Io block mapping behaviour was covering up a
> > bunch of other bugs in the delayed allocation extent/page cache
> > state coherency mappings. Essentially, we punch out the page cache
> > in quite a few places without first cleaning up delayed allocation
> > extents over that range and that exposes all sorts of nasty issues
> > once the direct IO mapping changes are made.  All of these are
> > existing problems, most of them are very unlikely to be seen in the
> > wild.
> > 
> > This patch set passes xfstests on a 4k block size/4k page size
> > config with out problems. However, there is still a fsx failure in
> > generic/127 on 1k block size/4k page size configurations that I
> > haven't yet tracked down. That test was failing occasionally before
> > this patch set as well, so it may be a completely unrelated problem.
> > 
> > The sad fact of this patchset is it is mostly playing whack-a-mole
> > with visible symptoms of bugs.  It drives home the fact that
> > bufferheads and the keeping of internal filesystem state attached to
> > the page cache simply isn't a verifiable architecture.  After
> > spending several days of doing nothing else but tracking down these
> > inconsistencies i can only conclude that the code is complex,
> > fragile and extremely difficult to verify that behaviour is correct.
> > As such, I doubt that the fixes are entirely correct, so I'm left
> > with using fsx and fsstress to tell me if I've broken anything.
> > 
> > Eyeballs appreciated, as is test results.
> > 
> 
> I had an xfstests running against this (on for-next) over the weekend
> and it hit the following bug on xfs/297:
> 
> [ 6408.168767] kernel BUG at fs/xfs/xfs_aops.c:1336!
> [ 6408.169542] invalid opcode: 0000 [#1] SMP 

Ok, so that's found another stale delalloc range where there
shouldn't be. I know there were still problems when I left because
generic/127 was failing on 1k block size filesystems, but I haven't
yet had a chance to get back to determine if the bug was the broken
code in xfs_check_page_types() that Dan Carpenter noticed. Were you
running with that fix?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs