On Nov 29, 2007 00:48 +0100, Jörn Engel wrote: > I didn't follow the discussion much, since it didn't appear to suit > logfs too well. In a nutshell, logfs is purely block-based, prepends > every block with a header, may compress blocks and packs them as tightly > as possible (byte alignment). The FIEMAP interface in some ways well suited to your needs, because it uses byte offsets instead of FIBMAP, which uses block offsets. I now see that one hole in the specification is that your physical extent is not the same length as the logical extent that the data represents. I'm not sure that is in itself a reason not to use FIEMAP. There is already a provision for logical extents that do not map directly to the physical layout (i.e. FIEMAP_EXTENT_NO_DIRECT flag on the extent). In the case of logfs, the extent fe_length would represent the logical length of the data that the extent covers, fe_offset is the start of the physical extent, and FIEMAP_EXTENT_NO_DIRECT indicates that this extent cannot be directly mapped. This is useful for applications like LILO that would otherwise assume the physical offset can be used to access the data from the block device. It would still provide very useful information about the layout of files on disk for filefrag, and if tar or cp used FIEMAP they could know to read the data from the start up to the end of an extent to avoid waiting for a seek in the middle of the IO, and of course skipping holes during copy. A very smart tar might even FIEMAP a whole bunch of files and then read the extents in physical block offset order to reduce seeking. I don't think most applications will care about the actual physical location of an extent, so much as the relative locations of extents within a file and between files. > Maybe the "MAP" part fooled me to believe FIEMAP would also expose > physical location of extends on the medium. But reading the proposal > again, I am unsure about that part. If physical locations are exposed, > SEEK_HOLE/SEEK_DATA is significantly more elegant for logfs. If not, > FIEMAP could be useful. SEEK_HOLE/SEEK_DATA only provides a fraction of the useful information that FIEMAP does. It won't give users or developers any information about the on disk layout (which is quite important for knowing if allocation algorithms are good). Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
