From: Eric Sandeen <sandeen@redhat.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Felipe Monteiro de Carvalho <felipemonteiro.carvalho@gmail.com>,
linux-ext4@vger.kernel.org
Subject: Re: Too large value in inode.i_blocks[1]
Date: Wed, 12 Jun 2013 09:25:36 -0500 [thread overview]
Message-ID: <51B884E0.5000405@redhat.com> (raw)
In-Reply-To: <20130612135204.GA27403@thunk.org>
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
next prev parent reply other threads:[~2013-06-12 14:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-12 5:08 Too large value in inode.i_blocks[1] Felipe Monteiro de Carvalho
2013-06-12 12:59 ` Theodore Ts'o
2013-06-12 13:34 ` Felipe Monteiro de Carvalho
2013-06-12 13:52 ` Theodore Ts'o
2013-06-12 14:25 ` Eric Sandeen [this message]
2013-07-01 15:15 ` Felipe Monteiro de Carvalho
2013-07-01 17:02 ` Theodore Ts'o
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=51B884E0.5000405@redhat.com \
--to=sandeen@redhat.com \
--cc=felipemonteiro.carvalho@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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 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).