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
