I just took a look at the extra lvm patch (v1.0.7) that Axel has added to
his AT kernel. It's touching fs/buffer.c and fs/super.c as well as
[reiser|ext3]/[buffer.c|super.c] but nothing in the xfs tree. Since two of
the errors I've seen mention xfs_da_do_buf and xfs_btree_check_sblock I'm
going to take a wild guess that this is the problem. IANAKD, so I could be
wrong.
I'm going to give Jan-Frode's kernel a go and see if it's got the same problem.
Cheers,
Dan
Dan Yocum wrote:
> Nathan,
>
> If an md device decided to go wonko would that make it look like a FS
> corruption? For instance, these FSs are RAID50 (hw raid5, sw raid0) across
> 3 volumes. I got to thinking about the kernel I've been using from ATrpms
> and I know he added an LVM patch. I haven't looked at it, yet, but maybe it
> touches something in the kernel that md doesn't like. Also, now that I'm
> back to my old standby kernel (2.4.18-26 + XFS v1.2) I'm not getting these
> errors/traces.
>
> Thoughts?
>
> Thanks,
> Dan
>
> Nathan Scott wrote:
>
>>On Mon, Mar 15, 2004 at 11:38:59AM -0600, Dan Yocum wrote:
>>
>>
>>>I don't know, yet, if this is a hardware or a software problem. I'm trying
>>>to figure that out.
>>>
>>>I'm using the ATRpms kernel (2.4.20-30_37 w XFSv1.3.0 et al. see the list at
>>>http://atrpms.physik.fu-berlin.de/dist/rh73/kernel/ ) and I'm getting these
>>>errors and sometimes it forces the FS offline or makes the system unusable -
>>>not really a freeze, but you can't interrupt it.
>>>
>>>Mar 1 14:21:25 sdssdp37 kernel: Filesystem "md(9,3)": XFS internal error
>>>xfs_btree_check_sblock at line 341 of file xfs_btree.c. Caller 0xf886c543
>>>...
>>>...
>>>Trace; f88566df <[xfs]xfs_btree_check_sblock+9f/c0>
>>>Trace; f88b4778 <[xfs].rodata.end+6179/14461>
>>>Trace; f88b473b <[xfs].rodata.end+613c/14461>
>>>Trace; f8841909 <[xfs]xfs_alloc_increment+159/180>
>>>Trace; f8841909 <[xfs]xfs_alloc_increment+159/180>
>>>Trace; f885667f <[xfs]xfs_btree_check_sblock+3f/c0>
>>>Trace; f88405e9 <[xfs]xfs_alloc_lookup+289/350>
>>>Trace; f883d60a <[xfs]xfs_alloc_ag_vextent_size+4a/440>
>>
>>
>>Hi Dan,
>>
>>Looks like you've got filesystem corruption, from your trace it
>>looks like its in one of the freespace btrees in an AG header.
>>Its difficult to diagnose whether this is caused by a hardware
>>or software failure - if you can find a pattern or better yet a
>>reproducible test case, that'd help us alot in figuring it out.
>>The output from xfs_repair may provide us additional clues also.
>>
>>thanks.
>>
>
>
--
Dan Yocum
Sloan Digital Sky Survey, Fermilab 630.840.6509
yocum@xxxxxxxx, http://www.sdss.org
SDSS. Mapping the Universe. There is no spoon.
|