From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: xfsprogs 3.1.0 repair problems?
Date: Fri, 15 Jan 2010 14:47:50 -0600 [thread overview]
Message-ID: <4B50D476.2040407@sandeen.net> (raw)
In-Reply-To: <20100115055628.GD28498@discord.disaster>
Dave Chinner wrote:
> On Thu, Jan 14, 2010 at 09:08:46PM -0600, Eric Sandeen wrote:
>> It looks like maybe the freespace checking isn't quite up to par:
>>
>> test 073 is dying with:
>>
>> _check_xfs_filesystem: filesystem on /mnt/test/14309.image is inconsistent
>> *** xfs_repair -n output ***
>> Phase 1 - find and verify superblock...
>> Phase 2 - using internal log
>> - scan filesystem freespace and inode maps...
>> sb_fdblocks 26156829, counted 26157853
>> - found root inode chunk
>
> This is caused by the remount,ro done in the test - the superblock
> is written to disk with the reserved blocks considered used. At
> unmount time those reserve blocks are "freed" before the superblock
> is written and so the total is correct at that time.
>
> I'm going to go look at the kernel code now...
>
> Cheers,
>
> Dave.
Today, I'm intermittently getting xfs_repair segfaults, in btree_get_prev,
but this seems odd:
Program terminated with signal 11, Segmentation fault.
#0 btree_get_prev (key=0x9fc330, root=0x9fc300) at btree.c:190
p190 if (cur->index > 0) {
(gdb) list btree.c:190
185 {
186 struct btree_cursor *cur = root->cursor;
187 int level = 0;
188 struct btree_node *node;
189
190 if (cur->index > 0) {
191 if (key)
192 *key = cur->node->keys[cur->index - 1];
193 return cur->node->ptrs[cur->index - 1];
194 }
(gdb) p *root
$1 = {root_node = 0x7fca8400fac0, cursor = 0x7fca8400e0e0, height = 1, keys_valid = 1, cur_key = 6792640, next_key = 0, next_value = 0x0, prev_key = 0, prev_value = 0x0}
(gdb) p cur
$2 = (struct btree_cursor *) 0x0
(gdb) quit
root->cursor is valid, but cur is not?
Still looking....
But maybe related to the initial problem... this is cropping up in
the post-test check & repair that xfstests does.
I imaged the filesystem before the checking in hopes of getting a
reproducer. When the testsuite runs, repair looks clean, but
then it segfaults.
If I then point repair at the filesystem image I created prior
to the segfault, it lights up with tons of errors. I'm confused
by that; one interesting thing is that repair is testing a mounted,
readonly filesystem when xfstests runs.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2010-01-15 20:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-15 3:08 xfsprogs 3.1.0 repair problems? Eric Sandeen
2010-01-15 3:52 ` Dave Chinner
2010-01-15 4:15 ` Eric Sandeen
2010-01-15 5:56 ` Dave Chinner
2010-01-15 20:47 ` Eric Sandeen [this message]
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=4B50D476.2040407@sandeen.net \
--to=sandeen@sandeen.net \
--cc=david@fromorbit.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