Messages in this thread | | | Date | Mon, 14 Jul 2008 17:30:35 +1000 | From | Dave Chinner <> | Subject | Re: xfs bug in 2.6.26-rc9 |
| |
On Fri, Jul 11, 2008 at 12:21:56PM +0200, Mikael Abrahamsson wrote: > On Fri, 11 Jul 2008, Dave Chinner wrote: > >> That aside, what was the assert failure reported prior to the oops? >> i.e. paste the lines in the log before the ---[ cut here ]--- line? One >> of them will start with 'Assertion failed:', I think.... > > These ones? > > Jul 8 04:44:56 via kernel: [554197.888008] Assertion failed: whichfork == XFS_ATTR_FORK || ip->i_delayed_blks == 0, file: fs/xfs/xfs_bmap.c, line: 5879 > Jul 9 03:25:21 via kernel: [42940.748007] Assertion failed: whichfork == XFS_ATTR_FORK || ip->i_delayed_blks == 0, file: fs/xfs/xfs_bmap.c, line: 5879
That implies a flush to disk failed to write everything, but no error was reported back to the flush. Not particularly conclusive what caused your problem.
That being said, it's not a fatal error - it simply means that the bmap will return a bogus block number reported for the delalloc extent that still exists.
This implies an in-memory error, not an on-disk error...
> I should also say that this assert failue happened two nights in a row so > I guess it's fairly reproducible (didn't happen on the 10th, and today, > the 11th it seems to have panic:ed around 03:30 (I start the > defragmentation via cron at 03:00) which I think is related.
Can you find the file it is failing on and run 'xfs_bmap -vvp <file>' to just extract the extent map outside the context of xfs_fsr?
Cheers,
Dave. -- Dave Chinner david@fromorbit.com
| |