Re: Too large value in inode.i_blocks[1]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 6/12/13 8:52 AM, Theodore Ts'o wrote:
> On Wed, Jun 12, 2013 at 01:34:37PM +0000, Felipe Monteiro de Carvalho wrote:
>> I see that i_block has 15*4=60 bytes, and with EXTENTS_FL the first 12 bytes 
>> of i_block are filled with a ext4_extent_header
>>
>> What about the rest of it? I couldn't understand from the wiki page what
>> the rest holds exactly, it is not 100% clear ...
>>
>> My first guess would be that it has in this order:
>>
>> ext4_extent_header, 12 bytes long
>> ext4_extent_idx, 12 bytes long:
>> ext4_extent, 12 bytes long
>> ext4_extent_tail 4 bytes long
> 
> The ext4_extent_tail is not used in i_blocks[].  There will be up to 4
> ext4_extent structures, or ext4_extent_idx structures, depending on
> the depth of the tree.  The ext4_extent_idx structures are used for
> the interior inodes of the tree.  The ext4_extent structures are used
> for the leaf nodes of the tree.  The ext4_extent_tail is used in
> extent tree blocks so we can checksum the metadata if the
> metadata_csum feature is enabled.  The entire inode is checksummed, so
> we don't need the ext4_extent_tail in i_blocks[].
> 
>> Please don't worry that I am not frivolously attempting to access the
>> file system directly. My project explictly requires this, it is a
>> recovery tool to repair damaged file systems, and it must work in
>> Windows and Mac OS X. Maybe libext2fs works outside Linux, not sure, 
>> but anyway we already have source code for reading/recovering ext2/3, 
>> I am just expanding it to ext4. External dependencies are always
>> not ideal.
> 
> Libext2fs is designed to be cross OS portable.  It's used for the FUSE
> extensions that allow Mac and Windows machines to access ext2/3/4 file
> systems.  And libext2fs is designed to work with corrupted file
> systems, since after e2fsck is the normal tool most people use to
> repair damaged file systems, and debugfs is the command line tool
> which is used by people to examine file systems, corrupt fie systems
> for e2fsck test cases, and in a few cases, attempt to do manual repair
> of file systems in some extreme circumstances.

Indeed, I know of at least one "clean room" ext3 driver for windows
which did a fine job of corrupting proper ext3 filesystems, because it
was written incorrectly and didn't use the standard body of code.
Wasted a lot of my time getting to the bottom of that one.  :(

-Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux