On Thu, 2007-11-29 at 00:48 +0100, Jörn Engel wrote: > 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 > I'd have to reread the original proposal, but I remember FIEMAP as being a generalized way of getting information about a files extents. I think the original proposal only dealt with mapping file offsets to physical extents, but IIRC the interface was flexible enough to implement a "where are the holes" request. Regardless, SEEK_HOLE/SEEK_DATA being a better suited interface for the needs of logfs doesn't make it the best interface for that need. -- Nicholas Miell <nmiell@xxxxxxxxxxx> - 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
