How to understand super.c/descriptor_loc for ext2/ext3/ext4?

[openspace.wang@gmail.com (Ryan Wang)]

Hi,

I'm reading the source code for ext2/ext3/ext4, and cannot figure
out how descriptor_loc() runs:

1600static ext3_fsblk_t descriptor_loc(struct super_block *sb,
1601                                    ext3_fsblk_t logic_sb_block,
1602                                    int nr)
1603{
1604        struct ext3_sb_info *sbi = EXT3_SB(sb);
1605        unsigned long bg, first_meta_bg;
1606        int has_super = 0;
1607
1608        first_meta_bg = le32_to_cpu(sbi->s_es->s_first_meta_bg);


1) Who can setup the field ->s_first_meta_bg, mke2fs? And what does it mean?
   What's a meta block group?

1609
1610        if (!EXT3_HAS_INCOMPAT_FEATURE(sb,
EXT3_FEATURE_INCOMPAT_META_BG) ||
1611            nr < first_meta_bg)

2) In which case, we can have "nr < first_meta_bg"?
   And how does EXT3_FEATURE_INCOMPAT_META_BG affect the physical disk
layout?


1612                return (logic_sb_block + nr + 1);
1613        bg = sbi->s_desc_per_block * nr;
1614        if (ext3_bg_has_super(sb, bg))
1615                has_super = 1;
1616        return (has_super + ext3_group_first_block_no(sb, bg));

3) It always return the first block no of the specific bg, right?
   Then its caller ext3_fill_super will read in the disk block.
   It seems that ext3_fill_super just read many copies of one same block
   (1st block), right?

   I'm sure I'm wrong with it, but cannot find out the right way.

1617}


Any explanation are welcome.

thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120608/587b9a33/attachment-0001.html