From: Andreas Dilger <adilger@sun.com>
To: Etienne Lorrain <etienne_lorrain@yahoo.fr>
Cc: linux-ext4@vger.kernel.org
Subject: Re: on disk format: value of bg_inode_table_hi?
Date: Wed, 28 Jan 2009 11:01:37 -0700 [thread overview]
Message-ID: <20090128180137.GD3652@webber.adilger.int> (raw)
In-Reply-To: <736081.19431.qm@web23606.mail.ird.yahoo.com>
On Jan 28, 2009 00:20 +0000, Etienne Lorrain wrote:
> I have created an ext4 fs on a 64 Mb USB disk by "mkfs.ext4 /dev/sdb" on
> debian lenny (no partition). I have debugfs 1.41.3 (12-Oct-2008), so
> probably an up-to-date mkfs.ext4.
> When I analyse the filesystem using my own tools, I seem to read at least
> some bg_inode_table_hi values which are not null, on such a very small
> filesystem.
> Because the superblock s_feature_incompat has the 64BITS set, I assumed
> I should use those _hi fields.
> If I ignore the value of bg_inode_table_hi that I read as 512, I can at
> least analyse the few files I have put into it with debugfs (I strangely
> cannot mount that filesystem under debian).
Does "e2fsck -f" fix this problem? It definitely should.
> Here is the log I get from my debug softs (sorry, long lines):
> #### disk_analyse disk 2 i.e. EBIOS 0x01: (nb found = 6):
>
> ## open_filesystem Disk 2 part 0 type 0xE, read first 4 Kbytes: name already set to 'floppy'
>
> E2FS_get_parameter: Filesystem name: 'testext4' Filesystem opened (inode size 128, inodes_per_group 1912).
>
> FSname 'testext4': byte_per_block 1024 bytes, sector_per_block 2, first_data_block 1, inodes_count 15296, blocks_count 61,056.
>
> open_filesystem() success, Scan root directory: E2FS_get_sector_chain (inode 2): [E2FS_read_inode: inode 2, group 0, block 1] [bg_inode_table_hi = 512, bg_inode_table_lo = 273] i_blocks_lo 2 i_size_lo 1024: [create for lba 498] [read_analyse_chain: indirect blocknr == 0, level 1] [read_analyse_chain: indirect blocknr == 0, level 2] [read_analyse_chain: indirect blocknr == 0, level 3] 2 sectors at 498, OK
>
> [ignore: '/.'] [ignore: '/..'] [ignore: '/lost+found'] [is vmlinuz with header: '/vmlinuz-2.6.26-1-686'] [E2FS_read_inode: inode 12, group 0, block 11] [bg_inode_table_hi = 512, bg_inode_table_lo = 273] [E2FS_treat_directory: adding file 'vmlinuz-2.6.26-1-686' size 1505936 bytes] [is initrd: '/initrd.img-2.6.26-1-686'] [E2FS_read_inode: inode 13, group 0, block 12] [bg_inode_table_hi = 512, bg_inode_table_lo = 273] [E2FS_treat_directory: adding file 'initrd.img-2.6.26-1-686' size 7182236 bytes] [E2FS_read_inode: inode 14, group 0, block 13] [bg_inode_table_hi = 512, bg_inode_table_lo = 273] [E2FS_treat_directory: storing 'boot' directory at inode 14 size 1024] [E2FS_treat_directory: need to read more sectors] [file_treat: done, read 1024 bytes]
>
> (main dir size 1024)
>
> Scan /boot directory: E2FS_get_sector_chain (inode 14): [E2FS_read_inode: inode 14, group 0, block 13] [bg_inode_table_hi = 512, bg_inode_table_lo = 273] i_blocks_lo 2 i_size_lo 1024: [create for lba 21816] [read_analyse_chain: indirect blocknr == 0, level 1] [read_analyse_chain: indirect blocknr == 0, level 2] [read_analyse_chain: indirect blocknr == 0, level 3] 2 sectors at 21816, OK
>
> [ignore: '/boot/.'] [ignore: '/boot/..'] [is vmlinuz with header: '/boot/vmlinuz-2.6.26-1-686'] [E2FS_read_inode: inode 15, group 0, block 14] [bg_inode_table_hi = 512, bg_inode_table_lo = 273] [E2FS_treat_directory: adding file 'vmlinuz-2.6.26-1-686' size 1505936 bytes] [is initrd: '/boot/initrd.img-2.6.26-1-686'] [E2FS_read_inode: inode 16, group 0, block 15] [bg_inode_table_hi = 512, bg_inode_table_lo = 273] [E2FS_treat_directory: adding file 'initrd.img-2.6.26-1-686' size 7182236 bytes] [E2FS_treat_directory: need to read more sectors] [file_treat: done, read 1024 bytes]
>
> (/ScanPath directory size 1024) , end scan.
>
>
>
> So my question:
> Is that a bug on my side, a mis-interpretation of the use of that bg_inode_table_hi field, or a problem somewhere else?
>
> Thanks for any answer,
> Etienne.
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
next prev parent reply other threads:[~2009-01-28 18:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-28 0:20 on disk format: value of bg_inode_table_hi? Etienne Lorrain
2009-01-28 18:01 ` Andreas Dilger [this message]
2009-01-28 20:47 ` Etienne Lorrain
2009-01-29 5:12 ` Theodore Tso
2009-01-29 11:47 ` Etienne Lorrain
2009-01-30 4:19 ` Theodore Tso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090128180137.GD3652@webber.adilger.int \
--to=adilger@sun.com \
--cc=etienne_lorrain@yahoo.fr \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.