On Wed, 28 November 2007 16:39:59 -0700, Andreas Dilger wrote: > On Nov 28, 2007 14:56 -0800, Nicholas Miell wrote: > > > > type: one of EXTENT_TYPE_HOLE, EXTENT_TYPE_DATA, EXTENT_TYPE_EXTENTS, > > EXTENT_TYPE_COMPRESSED, EXTENT_TYPE_UNCOMPRESSED etc. > > This is what FIEMAP is supposed to do. We wrote a spec and implemented > a prototype for ext4, but haven't had time to make it generic to move > the large part of the code into the VFS. If someone wanted to take that > up, it would be much appreciated. > > See "[RFC] add FIEMAP ioctl to efficiently map file allocation" in > linux-fsdevel for details on this interface.
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). 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. Jörn -- Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest. -- Rob Pike - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
