Theodore Tso wrote: ... > The Extents and Blocks information display redundant information, so > what I've done is to change the patch so that if the file uses > extent-based block maps, the Extents information is displayed instead > of the BLOCKS information, and it is extended to include more > information, like this: > > ... > atime: 0x4a6d164e:82c08b38 -- Sun Jul 26 22:51:58 2009 > mtime: 0x4a6d164e:861ee098 -- Sun Jul 26 22:51:58 2009 > crtime: 0x4a6d164e:82c08b38 -- Sun Jul 26 22:51:58 2009 > Size of extra inode fields: 28 > EXTENTS: > (0-60 #61): 342272-342332, (61-127 #67 [uninit]): 537822-537888 Perhaps a bit late, but I find the "#<extent length>" reporting very unintuitive. Doesn't "#X" usually imply ordering? How about: (0-60 [61b]): 342272-342332, (61-127 [67b,uninit]): 537822-537888 ... or maybe some other ideas. IMHO it's all a bit hard to read anyway unless it's printed in a table format ala the new filefrag output. -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
