Hey, thanks for the info. Although.. On Thu, Aug 29, 2019 at 09:15:55AM +0200, Christoph Hellwig wrote: > 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. This seems doable, yes, but... Doing that essentially will make some filesystems, like BTRFS, to suddenly start to support fibmap, this was another reason why we opted in the first place to let filesystems know whom the caller was. We could maybe add a new FIEMAP_EXTENT_* flag in the future to, let's say, specify a specific block may be split between more than one device, but, well. It's an idea, but it won't change the fact BTRFS for example will suddenly start to support FIBMAP. -- Carlos
