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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.