On Fri, Aug 08, 2003 at 02:33:52PM +1000, Scott Fagg wrote:
>
> /proc/sys/fs/xfs/error_level is set to 3 on the box in question.
>
> What is the error message i'm getting actually telling me ?
>
> - corrupt filesystem structure ?
> - corrupt inode ?
> - it just ran out of space ? ( i didn't think this was the case as i still
> get problems after freeing up some free space)
>
> I'm guessing that what happens is that at the full-volume case is hit, an
> allocation goes wrong and the structures on disc don't get written out
> properly, so from that point on the fs is messed up.
>
> What puzzles me is that xfs_repair and xfs_check NEVER find any problems even
> while i'm getting these errors out of dmesg.
From your stack trace...
xfs_da_do_buf: bno 0
dir: inode 4688490
Filesystem "ida0(72,17)": XFS internal error xfs_da_do_buf(1) at line 2184 of
file xf+s_da_btree.c. Caller 0xc01952d7
cd797cc8 c0194b81 c02b1f5d 00000001 cfe6e400 c02b1eb8 00000888 c01952d7
c3c6dd40 cf741868 0000a201 00002000 0001a201 c3c6dd40 0023c530 00000001
00000000 cfe6e400 cd797d3c c01c4def 000003de 0023c530 00000000 00000010
Call Trace:
[<c0194b81>] xfs_da_do_buf+0x211/0x8b0 [kernel]
[<c01952d7>] xfs_da_read_buf+0x57/0x60 [kernel]
[<c01c4def>] xfs_trans_read_buf+0x33f/0x3a0 [kernel]
[<c01accb1>] xfs_itobp+0xf1/0x270 [kernel]
[<c01952d7>] xfs_da_read_buf+0x57/0x60 [kernel]
[<c019319a>] xfs_da_node_lookup_int+0x7a/0x330 [kernel]
[<c019319a>] xfs_da_node_lookup_int+0x7a/0x330 [kernel]
[<c017a3fc>] xfs_attr_node_get+0x3c/0xd0 [kernel]
[<c017b26f>] xfs_attr_fetch+0xff/0x1b0 [kernel]
[<c01707c4>] xfs_acl_iaccess+0x54/0xe0 [kernel]
[<c01982d0>] xfs_dir2_put_dirent64_direct+0x0/0xa0 [kernel]
[<c01b107c>] xfs_iaccess+0x19c/0x1b0 [kernel]
[<c01ca1fb>] xfs_access+0x3b/0x60 [kernel]
[<c01da9b9>] linvfs_permission+0x29/0x30 [kernel]
[<c0146bba>] permission+0x3a/0x40 [kernel]
You are doing a permissions check on an inode with an ACL. The
extended attribute part of the inode is in btree or node format,
hence we're down in xfs_da_do_buf (da= dir/attr) reading in the
extended attribute data.
For some strange reason we are trying to read at AG blk 0 for that
inode, which is wrong - block zero in an AG holds the SB/AGF/AGI/
AGFL for that allocation group. Its not clear if this is due to
the EA data on disk pointing to that block, or a bug in the kernel
code. The tools not finding anything suggests to me a kernel bug,
not sure where though...
cheers.
--
Nathan
|