On Thu, Aug 10, 2006 at 01:31:35PM +0200, Jesper Juhl wrote:
> On 08/08/06, Nathan Scott <[email protected]> wrote:
> ...
> Ok, I booted the server with 2.6.18-rc4 + your patch. Things went well
> for ~3 hours and then blew up - not in the same way though.
>
> The machine was under pretty heavy load recieving data via rsync when
> the following happened :
>
> Filesystem "dm-51": XFS internal error xfs_trans_cancel at line 1138
> of file fs/xfs/xfs_trans.c. Caller 0xc0210e3f
> [<c0103a3c>] show_trace_log_lvl+0x152/0x165
> [<c0103a5e>] show_trace+0xf/0x13
> [<c0103b59>] dump_stack+0x15/0x19
> [<c0213474>] xfs_trans_cancel+0xcf/0xf8
> [<c0210e3f>] xfs_rename+0x64d/0x936
> [<c0226286>] xfs_vn_rename+0x48/0x9f
> [<c016584e>] vfs_rename_other+0x99/0xcb
> [<c0165a36>] vfs_rename+0x1b6/0x1eb
> [<c0165bda>] do_rename+0x16f/0x193
> [<c0165c45>] sys_renameat+0x47/0x73
Thanks Jesper. Hmm, lessee - this is a cancelled dirty rename
transaction ... could be ondisk dir2 corruption (any chance this
filesystem was affected by 2.6.17's endian bug?), or something
else entirely. No I/O errors in the system log earlier or anything
like that?
> I was doing an lvmextend +xfs_resize of a different (XFS) filesystem
> on the same server at roughly the same time. But I'm not sure if
> that's related.
That wont be related, no.
> I'm currently running xfs_repair on the fs that blew up.
OK, I'd be interested to see if that reported any directory (or
other) issues.
cheers.
--
Nathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
