On Tue, Apr 01, 2014 at 07:17:57AM +1100, Dave Chinner wrote: > 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? > Ah, good point. I was running with the check_page_type() rework, but not the most recent fix. I'll plan to test again with that included. Brian > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
