On 6/1/18 7:36 AM, Carlos Maiolino wrote: > Hi, > > I've been working on a patchset to get rid of the ->bmap infrastructure. > > FIBMAP ioctl should be supported forever, so, basically I'm using Dave's idea to > use ->fiemap() implementation to handle FIBMAP ioctl, however, I've been facing > an issue with Ext4 FIEMAP in this case; basically: > > When issuing a FIEMAP ioctl to Ext4with something like this: > > fiemap->fm_start = block_num * blocksize; > fiemap->fm_length = 1; > fmap->fm_extent_count = 1; > > I was expecting the fiemap_extent returned, to contain the physical block > from the logical request above, so: > > physical block == fiemap_ext.fe_physical / blocksize > > > This works on XFS, which is using iomap_fiemap infrastructure. However, it > doesn't work on Ext4. > > Ext4 always returns in fiemap_ext.fe_physical, the start of the extent, and not > the offset requested initially (if it lies somewhere beyond the first block in > the extent). > > Ted, is there any restriction why ext4_fiemap isn't using iomap_fiemap()? Or any > reason why ext4 fiemap always returns the offset from the beginning of the > extent? Would you oppose to have it updated to return the offset initially > requested? Or maybe, change ext4_fiemap() to use iomap_fiemap()? > > I read the fiemap documentation, but I didn't get a clear understanding if > fiemap should be returning the beginning of the extent, the offset initially > requested, or if it depends on FS implementation. I think the fiemap docs[1] explicitly state that ext4's behavior is valid: > Extents returned mirror > those on disk - that is, the logical offset of the 1st returned extent > may start before fm_start, and the range covered by the last returned > extent may end after fm_length. so if you're going to use this, you will need to work out //your// block based on the overlapping extent that gets returned, just like userspace would do. -Eric [1] Documentation/filesystems/fiemap.txt
