kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
* How to understand super.c/descriptor_loc for ext2/ext3/ext4?
@ 2012-06-07 13:37 Ryan Wang
  0 siblings, 0 replies; 2+ messages in thread
From: Ryan Wang @ 2012-06-07 13:37 UTC (permalink / raw)
  To: kernelnewbies

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 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* How to understand super.c/descriptor_loc for ext2/ext3/ext4?
@ 2012-06-07 23:57 Ryan Wang
  0 siblings, 0 replies; 2+ messages in thread
From: Ryan Wang @ 2012-06-07 23:57 UTC (permalink / raw)
  To: kernelnewbies

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 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-06-07 23:57 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-07 23:57 How to understand super.c/descriptor_loc for ext2/ext3/ext4? Ryan Wang
  -- strict thread matches above, loose matches on Subject: below --
2012-06-07 13:37 Ryan Wang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).