From: Stian Jordet <liste@jordet.net>
To: Nathan Scott <nathans@sgi.com>
Cc: Justin Piszcz <jpiszcz@lucidpixels.com>, xfs@oss.sgi.com
Subject: Re: xfs bug in 2.6.17.9?
Date: Fri, 25 Aug 2006 10:38:48 +0200 [thread overview]
Message-ID: <44EEB718.4060805@jordet.net> (raw)
In-Reply-To: <1156486538.6854.1.camel@localhost.localdomain>
Stian Jordet wrote:
> fre, 25,.08.2006 kl. 11.58 +1000, skrev Nathan Scott:
>
>> This is likely to be lost+found being recreated each time, its
>> normal if you don't do something about the lost+found files -
>> once those are renamed/removed, it should run cleanly.
>>
>
> You seem to be right about that :)
>
> But when I wake up this morning, I had my logs full of this:
>
> 0x0: 24 73 74 61 74 73 20 3d 20 7b 0a 20 20 27 73 68
> Filesystem "rd/c0d1p1": XFS internal error xfs_da_do_buf(2) at line 2212
> of file fs/xfs/xfs_da_btree.c. Caller 0xc029d81c
> <c02b0b0b> xfs_corruption_error+0x10b/0x140 <c029d81c> xfs_da_read_buf
> +0x3c/0x40
> <c02e10a1> kmem_zone_alloc+0x61/0xe0 <c029cd9a> xfs_da_buf_make
> +0xfa/0x150
> <c029d719> xfs_da_do_buf+0x929/0x980 <c029d81c> xfs_da_read_buf
> +0x3c/0x40
> <c029d81c> xfs_da_read_buf+0x3c/0x40 <c02a05fd> xfs_da_node_lookup_int
> +0xcd/0x3b0
> <c02a05fd> xfs_da_node_lookup_int+0xcd/0x3b0 <c02a899f>
> xfs_dir2_node_lookup+0x3f/0xc0
> <c02a325a> xfs_dir2_lookup+0x12a/0x130 <c02e91e6> xfs_vn_permission
> +0x26/0x30
> <c016e220> vfs_permission+0x20/0x30 <c016e84a> __link_path_walk
> +0x8a/0xfa0
> <c02d58cc> xfs_dir_lookup_int+0x4c/0x130 <c02da1fe> xfs_lookup
> +0x7e/0xa0
> <c02e963e> xfs_vn_lookup+0x4e/0x90 <c016e119> __lookup_hash+0xe9/0x120
> <c0170088> do_unlinkat+0xa8/0x170 <c0168947> sys_stat64+0x27/0x30
> <c0102fcf> syscall_call+0x7/0xb
>
> Don't know how many times, but many! Is that related to anything...?
>
It seems I just hadn't used a recent enough xfs_repair with that
filesystem. Seems good now. Just one last question, are you 99,5% sure
that this is the symptoms of that corruption bug in 2.6.17? So I can
assume that my memory wasn't the problem? I'm now running with only
512MB (which I'm sure is good), and I don't want to use the new memory
if I get this problem again (even though I have good backups, it's a
hell of a job fixing it again...)
Thank you.
Best regards,
Stian
next prev parent reply other threads:[~2006-08-25 8:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-24 9:45 xfs bug in 2.6.17.9? Stian Jordet
2006-08-24 12:29 ` Martin Steigerwald
2006-08-24 23:45 ` Stian Jordet
2006-08-24 13:42 ` Justin Piszcz
2006-08-24 23:47 ` Stian Jordet
2006-08-25 1:58 ` Nathan Scott
2006-08-25 6:15 ` Stian Jordet
2006-08-25 8:38 ` Stian Jordet [this message]
2006-08-25 5:08 ` Chris Wedgwood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44EEB718.4060805@jordet.net \
--to=liste@jordet.net \
--cc=jpiszcz@lucidpixels.com \
--cc=nathans@sgi.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox