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

[Ryan Wang]

Hi,

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

1600 <http://lxr.linux.no/linux+*/fs/ext3/super.c#L1600>static
ext3_fsblk_t <http://lxr.linux.no/linux+*/+code=ext3_fsblk_t>
descriptor_loc <http://lxr.linux.no/linux+*/+code=descriptor_loc>(struct
super_block <http://lxr.linux.no/linux+*/+code=super_block> *sb
<http://lxr.linux.no/linux+*/+code=sb>,1601
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1601>
                ext3_fsblk_t
<http://lxr.linux.no/linux+*/+code=ext3_fsblk_t> logic_sb_block
<http://lxr.linux.no/linux+*/+code=logic_sb_block>,1602
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1602>
                int nr <http://lxr.linux.no/linux+*/+code=nr>)1603
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1603>{1604
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1604>        struct
ext3_sb_info <http://lxr.linux.no/linux+*/+code=ext3_sb_info> *sbi
<http://lxr.linux.no/linux+*/+code=sbi> = EXT3_SB
<http://lxr.linux.no/linux+*/+code=EXT3_SB>(sb
<http://lxr.linux.no/linux+*/+code=sb>);1605
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1605>        unsigned
long bg <http://lxr.linux.no/linux+*/+code=bg>, first_meta_bg
<http://lxr.linux.no/linux+*/+code=first_meta_bg>;1606
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1606>        int
has_super <http://lxr.linux.no/linux+*/+code=has_super> = 0;1607
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1607>1608
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1608>
first_meta_bg <http://lxr.linux.no/linux+*/+code=first_meta_bg> =
le32_to_cpu <http://lxr.linux.no/linux+*/+code=le32_to_cpu>(sbi
<http://lxr.linux.no/linux+*/+code=sbi>->s_es
<http://lxr.linux.no/linux+*/+code=s_es>->s_first_meta_bg
<http://lxr.linux.no/linux+*/+code=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 <http://lxr.linux.no/linux+*/fs/ext3/super.c#L1609>1610
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1610>        if
(!EXT3_HAS_INCOMPAT_FEATURE
<http://lxr.linux.no/linux+*/+code=EXT3_HAS_INCOMPAT_FEATURE>(sb
<http://lxr.linux.no/linux+*/+code=sb>, EXT3_FEATURE_INCOMPAT_META_BG
<http://lxr.linux.no/linux+*/+code=EXT3_FEATURE_INCOMPAT_META_BG>)
||1611 <http://lxr.linux.no/linux+*/fs/ext3/super.c#L1611>
nr <http://lxr.linux.no/linux+*/+code=nr> < first_meta_bg
<http://lxr.linux.no/linux+*/+code=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 <http://lxr.linux.no/linux+*/fs/ext3/super.c#L1612>
 return (logic_sb_block
<http://lxr.linux.no/linux+*/+code=logic_sb_block> + nr
<http://lxr.linux.no/linux+*/+code=nr> + 1);1613
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1613>        bg
<http://lxr.linux.no/linux+*/+code=bg> = sbi
<http://lxr.linux.no/linux+*/+code=sbi>->s_desc_per_block
<http://lxr.linux.no/linux+*/+code=s_desc_per_block> * nr
<http://lxr.linux.no/linux+*/+code=nr>;1614
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1614>        if
(ext3_bg_has_super
<http://lxr.linux.no/linux+*/+code=ext3_bg_has_super>(sb
<http://lxr.linux.no/linux+*/+code=sb>, bg
<http://lxr.linux.no/linux+*/+code=bg>))1615
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1615>
has_super <http://lxr.linux.no/linux+*/+code=has_super> = 1;1616
<http://lxr.linux.no/linux+*/fs/ext3/super.c#L1616>        return
(has_super <http://lxr.linux.no/linux+*/+code=has_super> +
ext3_group_first_block_no
<http://lxr.linux.no/linux+*/+code=ext3_group_first_block_no>(sb
<http://lxr.linux.no/linux+*/+code=sb>, bg
<http://lxr.linux.no/linux+*/+code=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 <http://lxr.linux.no/linux+*/fs/ext3/super.c#L1617>}


Any explanation are welcome.

thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120607/cc78e653/attachment.html