On Tue, Apr 17, 2018 at 9:57 AM, Darrick J. Wong <[email protected]> wrote: > On Tue, Apr 17, 2018 at 09:53:47AM -0700, Dan Williams wrote: >> On Tue, Apr 17, 2018 at 9:10 AM, Christoph Hellwig <[email protected]> >> 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.
Right, all I am trying to determine is if this is a regression or not. It seems not supporting bmap on dax going forward is a feature not a bug. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
