From: Dave Chinner <david@fromorbit.com>
To: Richard Sharpe <realrichardsharpe@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: Possible small bug in xfsprogs-dev/db/metadump.c
Date: Wed, 30 Sep 2009 10:16:47 +1000 [thread overview]
Message-ID: <20090930001647.GI9464@discord.disaster> (raw)
In-Reply-To: <46b8a8850909290845o22589155ud1ab403b761e734c@mail.gmail.com>
On Tue, Sep 29, 2009 at 08:45:56AM -0700, Richard Sharpe wrote:
> However, now I understand what is going on.
>
> Assume a free space tree with levels = 3 (from the AGF). However, not
> all leaf nodes will be at depth 3 in the tree, some will be at depth 2
> in the tree.
No, that is not possible. By definition, a consistent filesystem
image has all leaf nodes at level zero.
> However, in scanfunc_freesp we see:
>
> if (level == 0)
> return 1;
>
> numrecs = be16_to_cpu(block->bb_numrecs);
> if (numrecs > mp->m_alloc_mxr[1]) {
> if (show_warnings)
> print_warning("invalid numrecs (%u) in %s block %u/%u",
> numrecs, typtab[btype].name, agno, agbno);
> return 1;
> }
>
> If we hit level == 0 then we exit, however, for a leaf node that is at
> depth 2 (level 1, but bb_level == 0) we will see numrecs >
> mp->m_alloc_mxr[1] and will also skip such records (ie, will not
> recurse into them).
This sounds to me like the log has not been replayed on this
filesystem. AFAICT, when looking at a raw disk image of an XFS
filesystem, the only way to get leaf nodes at non-zero levels is to
have a dirty log. i.e. the log contains allocation/free transactions
that have resulted in a multi-level rebalance of the tree
that have not been replayed and written to disk and hence on-disk
image of the tree is unbalanced. When the log is replayed, the
on disk image will get updated and the tree will appear balanced
with all leaves at level 0.
> However, if the user does "metadump -w" they will see warnings that
> are bogus and suggests that the author was not really aware of the
> real structure of the tree.
I think he was aware of the structure. ;)
It seems to me that you are trying to use the wrong tool to walk
free space trees and interpret the number of extents. xfs_metadump
is intended to capture the exact layout of the filesystem metadata
so that it can be reproduced exactly in a different environment. It
was not intended as a method of interpreting the potentially
inconsistent metadata that it records.
xfs_db does what you are trying to do. It already has commands that
walk the per AG free space trees and tells you the number of
extents, gives an extent size histogram, etc....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2009-09-30 0:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <46b8a8850909271220w372d60c3s18a543ed00825082@mail.gmail.com>
2009-09-28 17:21 ` Possible small bug in xfsprogs-dev/db/metadump.c Christoph Hellwig
2009-09-28 17:36 ` Richard Sharpe
2009-09-29 13:00 ` Christoph Hellwig
2009-09-29 15:45 ` Richard Sharpe
2009-09-30 0:16 ` Dave Chinner [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=20090930001647.GI9464@discord.disaster \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=realrichardsharpe@gmail.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