[Top] [All Lists]

Re: Possible small bug in xfsprogs-dev/db/metadump.c

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: Possible small bug in xfsprogs-dev/db/metadump.c
From: Richard Sharpe <realrichardsharpe@xxxxxxxxx>
Date: Tue, 29 Sep 2009 08:45:56 -0700
Cc: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZGxSK65lBlhIXCYGvjLjIporv+b1QDFCDlQjGcKoz0Y=; b=Wq6ACALUcfKu8Zv+/bqckehkJOQB9YKa7Dt4phR5tz+oX9DJClpze/AMkiLq/C2iPp LdNiAgzWM4ckZ6Nri36tkm1gIIBu6NtSO92KD29wBHedv3S9U4OuwJLVqwLlkOSaLEue 0bnxWNMXNcQsYz6nZime6F+kt08GQjTrU6Mjc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NfXatkwRpQoeUzw8dTlgPvj/OGzq1mKMdh7xUKR7+T0brFufIs24XEg/PwTBPIKSBs uDyKvXXE5SBKo5PCwCNyJIhIYiHnK8P2abw20evxeq3dyfrZu5COdq3aUG1tcrr6kNEa keXSNoBzJzovT9Ap8koejix7OByiwXTlnu41E=
In-reply-to: <20090929130022.GD11375@xxxxxxxxxxxxx>
References: <46b8a8850909271220w372d60c3s18a543ed00825082@xxxxxxxxxxxxxx> <20090928172137.GA21868@xxxxxxxxxxxxx> <46b8a8850909281036j1bdbf61h18b4134912735d92@xxxxxxxxxxxxxx> <20090929130022.GD11375@xxxxxxxxxxxxx>
On Tue, Sep 29, 2009 at 6:00 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> On Mon, Sep 28, 2009 at 10:36:13AM -0700, Richard Sharpe wrote:
>> Well, yes there is, but that is the problem I encountered. It is level
>> as passed in when starting at the top of the tree, which is obtained
>> from the levels value in the AGF, and is decremented by one on each
>> recursion:
>>         if (!(*func)(iocur_top->data, agno, agbno, level - 1, btype, arg))
>> However, what should really be looked at is the value bb_level in the
>> header in each free-space Btree node.
> I think bother are equally valid.  The one passed in fro mthe top should
> always be right while the ondisk one might be corrupted.

Well, yes, but then anything could be corrupted on disk, including the
superblock and the pointers in interior nodes in the free space Btree.

>> After I made that change to my changes, I started being able to
>> properly count all leaf nodes and free extents, and the numbers came
>> out where I expected them to be (instead of not seeing many leaf nodes
>> and vastly undercounting free extents).
> Still not quite understanding your problem here.  Do you have a tool
> of your own that doesn't start from the btree root but only walks
> subtrees?  In that case you need to look at the on-disk level unless
> you can find out easily what level you start at.  But I don't think we
> need this for the existing tools that always walk from the root.

No, I was walking down from the root of the tree.

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.

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).

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 do think it is a minor issue since it will not lead to dropping any
records as I first feared.

Since I wanted to count the number of free extents in the free-space
trees I needed to actually see all leaf nodes, and thus it became a
problem for me.

Richard Sharpe

<Prev in Thread] Current Thread [Next in Thread>