On Tue, Sep 29, 2009 at 5:16 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> 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.
I got back to this today and reproduced my test case, and you are correct.
> 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.
Dunno. I just umounted again ...
>> 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 was, in fact, I who was confused ... I apologize for the statement I made.
> 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....