On Tue, Apr 17, 2018 at 10:40:59PM +0800, Xiong Zhou wrote: > We got these in v4.17-rc1: > 6e2608d xfs, dax: introduce xfs_dax_aops > fb094c9 ext2, dax: introduce ext2_dax_aops > 5f0663b ext4, dax: introduce ext4_dax_aops > > And we don't have ->bmap call in these aops, which may lead > to the ioctl call failure. > > Do we have any plan of adding/supporting it ? > > xfstests generic/223 covers this issue. If we are not going > to support this call for dax, we need to fix the testcase. Not supporting ->bmap is a good thing as it is hightly dangerous.

On Tue, Apr 17, 2018 at 09:53:47AM -0700, Dan Williams wrote: > On Tue, Apr 17, 2018 at 9:10 AM, Christoph Hellwig <hch(a)infradead.org&gt; wrote: > > On Tue, Apr 17, 2018 at 10:40:59PM +0800, Xiong Zhou wrote: > >> We got these in v4.17-rc1: > >> 6e2608d xfs, dax: introduce xfs_dax_aops > >> fb094c9 ext2, dax: introduce ext2_dax_aops > >> 5f0663b ext4, dax: introduce ext4_dax_aops > >> > >> And we don't have ->bmap call in these aops, which may lead > >> to the ioctl call failure. > >> > >> Do we have any plan of adding/supporting it ? > >> > >> xfstests generic/223 covers this issue. If we are not going > >> to support this call for dax, we need to fix the testcase. > > > > Not supporting ->bmap is a good thing as it is hightly dangerous. > > I take this to mean "don't fix, it is another casualty of dax being > experimental and it won't be coming back". I can get on board with > that. > > Otherwise, I was about to send a series adding bmap to {xfs,ext2,ext4}_dax_ops. Frankly I'd rather see the swapfile code learn how to iomap and then we can get rid of bmap in xfs entirely.