[Ocfs2-users] Understanding debugfs.ocfs2 output

[Sunil Mushran]

It is triggered when the inode or extent allocators (for all slots) have
no free space and the global bitmap does not have enough contiguous
bits to grow these allocators.

On 11/24/2010 05:36 AM, Norman P. B. Joseph wrote:
> Sunil,
>
> Thanks, that answers question #1 and maybe also question #2.  Would it
> be safe to assume then, that only when -all- of the Contig numbers in
> the extent_alloc output fall below the Clusters per Group X Bits per
> Cluster number is the "no space" issue triggered?
>
> -Norm
>
>
> On Tue, 2010-11-23 at 14:39 -0800, Sunil Mushran wrote:
>> The length of allocator chains in the global bitmap depends on
>> the size of the volume and block/cluster sizes. It is created during
>> format and only grows if the volume is grown. That's it.
>>
>> On 11/23/2010 11:04 AM, Norman P. B. Joseph wrote:
>>> This is related to the "No space on OCFS2 volume" error discussed here
>>> this past Sep/Oct.  Our Oracle support rep pointed us to Metalink note
>>> #1232702.1 and suggested we should script something up to periodically
>>> check the free contiguous blocks in the group chains for the volume in
>>> question.
>>>
>>> Reading the note, I get how to get Clusters per Group X Bits per Cluster
>>> from the "stat //extent_alloc:NNNN".  What I'm confused about is parsing
>>> the "stat //global_bitmap" section, and I thought I might have a better
>>> chance of getting an explanation from the audience here.
>>>
>>> I have 2 basic questions:
>>>
>>> 1) The note above says that a "highly fragmented volume will have many"
>>> Group Chain entries in the //global_bitmap section, but gives no
>>> guidance as to what constitutes "many".  I see ~240 in the 56 GB OCFS2
>>> partition in question.  Is that Low?  High?  Just Right?
>>>
>>> 2) The note also says to check the "Contig" values in the long list of
>>> Group Chains that follows in the //global_bitmap section.  Specifically,
>>> "If none are higher than the sum[sic] of "Clusters per Group * Bits per
>>> Cluster" the metadata extent file cannot be expanded..."  Here is a
>>> sample output below:
>>>
>>>           Group Chain: 8   Parent Inode: 11  Generation: 1861766630
>>>           CRC32: 00000000   ECC: 0000
>>>           ##   Block#            Total    Used     Free     Contig   Size
>>>           0    258048            32256    1026     31230    28159    4032
>>>           1    8096256           32256    1        32255    32255    4032
>>>
>>>           Group Chain: 9   Parent Inode: 11  Generation: 1861766630
>>>           CRC32: 00000000   ECC: 0000
>>>           ##   Block#            Total    Used     Free     Contig   Size
>>>           0    290304            32256    30721    1535     1535     4032
>>>           1    8128512           32256    1        32255    32255    4032
>>>
>>>           Group Chain: 10   Parent Inode: 11  Generation: 1861766630
>>>           CRC32: 00000000   ECC: 0000
>>>           ##   Block#            Total    Used     Free     Contig   Size
>>>           0    322560            32256    31745    511      511      4032
>>>           1    8160768           32256    1        32255    32255    4032
>>>
>>>           Group Chain: 11   Parent Inode: 11  Generation: 1861766630
>>>           CRC32: 00000000   ECC: 0000
>>>           ##   Block#            Total    Used     Free     Contig   Size
>>>           0    354816            32256    30721    1535     1535     4032
>>>           1    8193024           32256    1        32255    32255    4032
>>>
>>> Should I be considering -all- the Contig values from -all- the Group
>>> Chains listed when looking for issues, or should I be considering each
>>> chain individually?  IOW, is it only a problem when -all- the Contig
>>> values from -all- the chains are below the clusters X bits value, or is
>>> it only a problem when all of the Contig values for a -single- chain are
>>> below the cluster X bits value?
>>>
>>> Any pointers on valid interpretation of the output is appreciated.
>>>
>>> -Norm
>>>
>>>