* 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).