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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 17, 2018 at 10:50:07AM -0700, Darrick J. Wong wrote:
> On Tue, Apr 17, 2018 at 11:40:00AM -0600, Andreas Dilger wrote:
> > On Apr 17, 2018, at 10:57 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> 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@xxxxxxxxxxxxx> 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?

Yup. I do.

[ because grub has a history of corrupting filesystems on my
machines with it's obnoxious "probe for bootable OS images on update
by attempting to mount every block device in the system" behaviour. ]

> > It needed FIBMAP support to map the
> > kernel image for booting.

There's a difference between FIBMAP and ->bmap. One's a syscall
parameter under ABI constraints and the other is an internal
implementation.

We have to keep supporting FIBMAP forever, but we can re-implement
it internally using ->fiemap pretty damn easily - just replace the
bmap() implementation with a ->fiemap call and replace all the
direct ->bmap() calls with bmap(). Hence FIBMAP will continue to
work on all filesystems (including DAX!) and we get the ->bmap
crap out of the kernel.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux