https://bugzilla.kernel.org/show_bug.cgi?id=207367 --- Comment #13 from Theodore Tso (tytso@xxxxxxx) --- On Tue, Apr 21, 2020 at 09:45:54AM -0700, Christoph Hellwig wrote: > On Tue, Apr 21, 2020 at 06:29:10PM +0200, Jan Kara wrote: > > Well, there are two problems with this - firstly, ocfs2 is also using jbd2 > > and it knows nothing about iomap. So that would have to be implemented. > > Secondly, you have to somehow pass iomap ops to jbd2 so it all boils down > > to passing some callback to jbd2 during journal init to map blocks anyway > > as Dave said. And then it is upto filesystem to do the mapping - usually > > directly using its internal block mapping function - so no need for iomap > > AFAICT. > > You'll need to describe the mapping some how. So why not reuse an > existing mechanism instead of creating a new ad-hoc one? Well, we could argue that bmap() is an "existing mechanism" --- again, bmap() returns a u64, so it's perfectly fine. It's FIBMAP which is "fundamentally broken", not bmap(). If the goal is to eventually eliminate bmap() and aops->bmap(), sure, then we should force march all file systems to use iomap_bmap(), including ocfs2. Otherwise, if the goal alert users of FIBMAP when it's returning an corrutped block number, why not move the check if the block is larger than INT_MAX to ioctl_fibmap() in fs/ioctl.c, instead of in iomap_bmap()? If we can't fix this, I'm beginning to think that switching to iomap for fiemap and bmap is actually a lose for ext4. It's causing performance regressions, and now we see it's causing functionality regressions. Sure, it's saving a bit of code size, but is it really worth it to use iomap for fiemap/bmap? - Ted -- You are receiving this mail because: You are watching the assignee of the bug.
