Re: ioctl FIBMAP for dax gone in v4.17-rc1

[Andreas Dilger <adilger@dilger.ca>]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

On Apr 17, 2018, at 10:57 AM, Darrick J. Wong <darrick.wong@oracle.com> 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 <hch@infradead.org> 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.

Is anyone still using LILO to boot?  It needed FIBMAP support to map the
kernel image for booting.  I don't know if Grub needs FIBMAP support for
the early boot stages or not (it has minimal filesystem support in the
later stages), but it would be a shame if it wasn't possible to boot an
all-NVRAM system as a result of a missing ->bmap() method.  Alternately,
convince the Grub folks to use FIEMAP if that is available...

Cheers, Andreas






[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]