On Tue, Jul 07, 2020 at 05:43:09PM +0800, Anand Jain wrote: > On 2/7/20 7:43 pm, David Sterba wrote: > > On Thu, Jul 02, 2020 at 09:11:20AM +0000, Rebraca Dejan (BSOT/PJ-ES1-Bg) wrote: > >> Hi all, > >> > >> I'm collecting file extents for our application from BtrFs filesystem image. > >> I've noticed that for some files a get the "wrong" physical offset for > >> start of the extent. I verified it using hexdump of the filesystem > >> image: when dump the content starting from the address returned from > >> FIEMAP ioctl, I see that the content is absolutely different from the > >> content of the file itself. Also, the FIEMAP ioctl reports regular > >> extent, it is not inline. > > > > There are 3 address spaces: > > > > - device physical offsets > > - filesystem physical offsets > > - filesystem logical offsets > > > > What you seem to expect is that device physical and filesystem physical > > and the same. This is not true in general in btrfs and fiemap will > > return only the filesystem offsets. To get to the device offsets you'd > > need to do the reverse mapping. > > Do you think is it a good idea to rather update vfs? A quick check > indicates struct fiemap_extent has reserved space to hold the devid, and > should handle the backward compatibility issues. This was proposed a few years back on LSF/MM, whether to extend fiemap with the device related information or to add a completely new ioctl that would not have to extend the existing interface in a way that could become unwieldy.
