Latest working kernel version: 2.6.28 Earliest failing kernel version: 2.6.28 Distribution: Gentoo Hardware Environment: i686 I was figuring out ext4 with hexedit (don't ask), and I noticed that the extent structure is backwards. It's defined in ext4_extents.h with this order: block(32-bit), len(16), start_hi(16), start_lo(32) Here's what I see (including 12 byte header): 0A F3 01 00 04 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 3E 17 13 00 (another 36 bytes of zeros) You can see that the block is 0x13173e, len is 1, and start is 0. (The header's just fine, and only says that there is 1 extent and there can be no more than 4 extents.)
It'd be a good trick to have the on-disk format not match the header ;) For this file: debugfs: stat testfile Inode: 12 Type: regular Mode: 0644 Flags: 0x80000 Generation: 1797761550 Version: 0x00000000:00000001 User: 0 Group: 0 Size: 98304 File ACL: 0 Directory ACL: 0 Links: 1 Blockcount: 128 Fragment: Address: 0 Number: 0 Size: 0 ctime: 0x497b8705:5cc91558 -- Sat Jan 24 15:24:21 2009 atime: 0x497b86f8:c29715dc -- Sat Jan 24 15:24:08 2009 mtime: 0x497b8705:5cc91558 -- Sat Jan 24 15:24:21 2009 crtime: 0x497b86f8:c29715dc -- Sat Jan 24 15:24:08 2009 Size of extra inode fields: 28 Extended attributes stored in inode body: selinux = "unconfined_u:object_r:file_t:s0\000" (32) BLOCKS: (8-23):9256-9271 TOTAL: 16 (logical start 0x8, len 0x10, physical start 0x2428) the inode looks like this: 00421b00 a4 81 00 00 00 80 01 00 f8 86 7b 49 4b 87 7b 49 |..........{IK.{I| 00421b10 05 87 7b 49 00 00 00 00 00 00 01 00 80 00 00 00 |..{I............| 00421b20 00 00 08 00 01 00 00 00 0a f3 01 00 04 00 00 00 |................| 00421b30 00 00 00 00 08 00 00 00 10 00 00 00 28 24 00 00 |............($..| 00421b40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00421b60 00 00 00 00 0e aa 27 6b 00 00 00 00 00 00 00 00 |......'k........| 00421b70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00421b80 1c 00 00 00 6c 19 d5 e2 58 15 c9 5c dc 15 97 c2 |....l...X..\....| 00421b90 f8 86 7b 49 dc 15 97 c2 00 00 00 00 00 00 02 ea |..{I............| 00421ba0 07 06 40 00 00 00 00 00 20 00 00 00 00 00 00 00 |..@..... .......| 00421bb0 73 65 6c 69 6e 75 78 00 04 01 38 00 00 00 00 00 |selinux...8.....| 00421bc0 05 00 00 00 00 00 00 00 61 74 74 72 00 00 00 00 |........attr....| 00421bd0 00 00 00 00 00 00 00 00 76 34 6c 75 65 00 00 00 |........v4lue...| 00421be0 75 6e 63 6f 6e 66 69 6e 65 64 5f 75 3a 6f 62 6a |unconfined_u:obj| 00421bf0 65 63 74 5f 72 3a 66 69 6c 65 5f 74 3a 73 30 00 |ect_r:file_t:s0.| An extent looks like this: struct ext4_extent { __le32 ee_block; /* first logical block extent covers */ __le16 ee_len; /* number of blocks covered by extent */ __le16 ee_start_hi; /* high 16 bits of physical block */ __le32 ee_start_lo; /* low 32 bits of physical block */ }; The extents portion is here: 0a f3 01 00 04 00 00 00 |................| 00421b30 00 00 00 00 08 00 00 00 10 00 00 00 28 24 00 00 |............($..| ^logical 0x8^ ^len^ ^ hi^ ^start lo^ 0x16 0 0x2428 There is nothing wrong with this; you are just looking at it wrong.