From mboxrd@z Thu Jan 1 00:00:00 1970 From: openspace.wang@gmail.com (Ryan Wang) Date: Fri, 8 Jun 2012 07:57:05 +0800 Subject: How to understand super.c/descriptor_loc for ext2/ext3/ext4? Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 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