On Tue, Aug 20, 2019 at 03:01:18PM +0200, Carlos Maiolino wrote: > On Wed, Aug 14, 2019 at 01:18:37PM +0200, Christoph Hellwig wrote: > > The whole FIEMAP_KERNEL_FIBMAP thing looks very counter productive. > > bmap() should be able to make the right decision based on the passed > > in flags, no need to have a fake FIEMAP flag for that. > > Using the FIEMAP_KERNEL_FIBMAP flag, is a way to tell filesystems from where the > request came from, so filesystems can handle it differently. For example, we > can't allow in XFS a FIBMAP request on a COW/RTIME inode, and we use the FIBMAP > flag in such situations. But the whole point is that the file system should not have to know this. It is not the file systems business in any way to now where the call came from. The file system just needs to provide enough information so that the caller can make informed decisions. And in this case that means if any of FIEMAP_EXTENT_DELALLOC, FIEMAP_EXTENT_ENCODED, FIEMAP_EXTENT_DATA_ENCRYPTED, FIEMAP_EXTENT_NOT_ALIGNED, FIEMAP_EXTENT_DATA_INLINE, FIEMAP_EXTENT_DATA_TAIL, FIEMAP_EXTENT_UNWRITTEN or FIEMAP_EXTENT_SHARED is present the caller should fail the bmap request.
