On Wed, Sep 18, 2019 at 09:12:41AM -0700, Darrick J. Wong wrote: > On Wed, Sep 18, 2019 at 03:24:36PM +0200, Christoph Hellwig wrote: > > On Wed, Sep 18, 2019 at 10:13:04AM +0200, Carlos Maiolino wrote: > > > All checks are now made in the caller, bmap_fiemap() based on the filesystem's > > > returned flags in the fiemap structure. So, it will decide to pass the result > > > back, or just return -EINVAL. > > > > > > Well, there is no way for iomap (or bmap_fiemap now) detect the block is in a > > > realtime device, since we have no flags for that. > > > > > > Following Christoph's line of thought here, maybe we can add a new IOMAP_F_* so > > > the filesystem can notify iomap the extent is in a different device? I don't > > > know, just a thought. > > > > > > This would still keep the consistency of leaving bmap_fiemap() with the decision > > > of passing or not. > > > > I think this actually is a problem with FIEMAP as well, as it > > doesn't report that things are on a different device. So I guess for > > now we should fail FIEMAP on the RT device as well. > > Or enhance FIEMAP to report some kind of device id like I suggested a > while back... Yes, this is in my todo list Darrick, but as agreed previously, this will be in a different patchset. It simply does not belong here and will make this patchset much more complex than it should be. About this patch itself, there isn't much I can do here, and I think a XFS fix to make it reject FIEMAP for RT devices as Christoph suggested, belongs to a xfs-only patch, not to this one. I can do that too, but on a different patch, changing FS semantics simply does not belong in this patchset. Cheers. > > --D -- Carlos
