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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
