2009/1/12 Dave Chinner <david@xxxxxxxxxxxxx>: > On Mon, Jan 12, 2009 at 03:48:13AM +0300, Alexander Beregalov wrote: >> > Hmmmm - this might be getting closer to the source of the bug. >> > It's being detecting when reading in the buffer to do a left shift >> > now, not during the delete of a record. >> > >> > I'd suggest that you treat this as the same failure and continue >> > the bisect to try to find when no problems show up at all. >> >> 687b890a184fef263ebb773926e1f4aa69240d01 is the first bad commit. > > [XFS] implement generic xfs_btree_lshift > > Make the btree left shift code generic. Based on a patch from David > Chinner with lots of changes to follow the original btree implementations > more closely. While this loses some of the generic helper routines for > inserting/moving/removing records it also solves some of the one off bugs > in the original code and makes it easier to verify. > >> Does it make sense? > > Yes, a bug in that patch could corrupt the btree in memory which we then trip > over later in delrec before it has been written to disk. > > Thank you for isolating the problem to that commit - it greatly narrows down > the amount of code we need to search to find the bug. I'll have a look tonight > to see if I can spot the problem. It seems 9eaead5 (implement generic xfs_btree_rshift) is really guilty, unless the bug "XFS internal error xfs_btree_check_lblock at line 200 of file fs/xfs/xfs_btree.c:" which I posted 5 hours ago is completely different from the original bug message. I can not reproduce the bug on 278d0ca14. -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
