When running debugfs on a filesystem formatted with flex_bg, it prints out the relative offsets for the bitmaps and inode table badly on 64-bit systems, because the offset is computed as a large positive number instead of being a negative numer (which will not be printed at all):
Group 1: (Blocks 0x8000-0xffff) [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 0x0102 (+4294934786), Inode bitmap at 0x0202 (+4294935042)
Inode table at 0x037e-0x03fa (+4294935422)
The attached patch prints out the relative offsets for flex_bg groups as the offset within the reported group. This makes it more clear where the metadata is located, rather than simply printing some large negative number.
Group 1: (Blocks 0x8000-0xffff) [INODE_UNINIT, ITABLE_ZEROED]
Block bitmap at 0x0102 (group 0 +258), Inode bitmap at 0x0202 (group 0 +514)
Inode table at 0x037e-0x03fa (group 0 +894)
Signed-off-by: Andreas Dilger <[email protected]>
--
Cheers, Andreas
...with patch this time...
On 2010-11-25, at 02:57, Andreas Dilger wrote:
> When running debugfs on a filesystem formatted with flex_bg, it prints out the relative offsets for the bitmaps and inode table badly on 64-bit systems, because the offset is computed as a large positive number instead of being a negative numer (which will not be printed at all):
>
> Group 1: (Blocks 0x8000-0xffff) [INODE_UNINIT, ITABLE_ZEROED]
> Block bitmap at 0x0102 (+4294934786), Inode bitmap at 0x0202 (+4294935042)
> Inode table at 0x037e-0x03fa (+4294935422)
>
> The attached patch prints out the relative offsets for flex_bg groups as the offset within the reported group. This makes it more clear where the metadata is located, rather than simply printing some large negative number.
>
> Group 1: (Blocks 0x8000-0xffff) [INODE_UNINIT, ITABLE_ZEROED]
> Block bitmap at 0x0102 (group 0 +258), Inode bitmap at 0x0202 (group 0 +514)
> Inode table at 0x037e-0x03fa (group 0 +894)
>
> Signed-off-by: Andreas Dilger <[email protected]>
> --
Cheers, Andreas
On 2010-11-25, at 12:09, Andreas Dilger wrote:
> ...with patch this time...
Attached is an updated patch that makes the output a bit more verbose (to avoid line wraps) and doesn't fail the m_raid_opts test (which complains when "(+0)" is printed for each inode table).
> On 2010-11-25, at 02:57, Andreas Dilger wrote:
>> When running debugfs on a filesystem formatted with flex_bg, it prints out the relative offsets for the bitmaps and inode table badly on 64-bit systems, because the offset is computed as a large positive number instead of being a negative numer (which will not be printed at all):
>>
>> Group 1: (Blocks 0x8000-0xffff) [INODE_UNINIT, ITABLE_ZEROED]
>> Block bitmap at 0x0102 (+4294934786), Inode bitmap at 0x0202 (+4294935042)
>> Inode table at 0x037e-0x03fa (+4294935422)
>>
>> The attached patch prints out the relative offsets for flex_bg groups as the offset within the reported group. This makes it more clear where the metadata is located, rather than simply printing some large negative number.
>>
>> Group 1: (Blocks 0x8000-0xffff) [INODE_UNINIT, ITABLE_ZEROED]
>> Block bitmap at 0x0102 (group 0 +258), Inode bitmap at 0x0202 (group 0 +514)
>> Inode table at 0x037e-0x03fa (group 0 +894)
>>
>> Signed-off-by: Andreas Dilger <[email protected]>
>> --
>
Cheers, Andreas
--
Andreas Dilger
Lustre Technical Lead
Oracle Corporation Canada Inc.
On Fri, Nov 26, 2010 at 05:33:27PM -0700, Andreas Dilger wrote:
> On 2010-11-25, at 12:09, Andreas Dilger wrote:
> > ...with patch this time...
>
> Attached is an updated patch that makes the output a bit more
> verbose (to avoid line wraps) and doesn't fail the m_raid_opts test
> (which complains when "(+0)" is printed for each inode table).
Every time you write code of the form:
if (block >= first_block + !!itable && ...)
Gcc kills a kitten. Please, think of the kittens....
I rewrote that code as follows:
if ((block >= first_block) && (block <= last_block)) {
if (itable && block == first_block)
return;
printf(" (+%u)", (unsigned)(block - first_block));
} else if ...
I also changed the output to use "(bg #16 + 4)" since I think it's a
bit easier to understand than "(grp 16+4)".
Otherwise, I've added it to the e2fsprogs maint branch, thanks.
- Ted