On Mon, Nov 28, 2016 at 03:08:18PM -0800, Dan Williams wrote:
> On Mon, Nov 28, 2016 at 2:51 PM, Ross Zwisler
> <ross.zwisler@xxxxxxxxxxxxxxx> wrote:
> > On Mon, Nov 28, 2016 at 02:13:29PM -0800, Dan Williams wrote:
> >> On Mon, Nov 28, 2016 at 1:24 PM, Ross Zwisler
> >> <ross.zwisler@xxxxxxxxxxxxxxx> wrote:
> >> > On Mon, Nov 28, 2016 at 10:12:17PM +0100, Arnd Bergmann wrote:
> >> >> Without the get_block based I/O, we get warnings when CONFIG_FS_IOMAP
> >> >> is disabled:
> >> >>
> >> >> fs/dax.c:736:12: error: ‘dax_insert_mapping’ defined but not used [-Werror=unused-function]
> >> >> fs/dax.c:512:12: error: ‘copy_user_dax’ defined but not used [-Werror=unused-function]
> >> >> fs/dax.c:490:12: error: ‘dax_load_hole’ defined but not used [-Werror=unused-function]
> >> >> fs/dax.c:294:14: error: ‘grab_mapping_entry’ defined but not used [-Werror=unused-function]
> >> >>
> >> >> This patch blindly marks those as __maybe_unused, which avoids the warnings.
> >> >> However, I suspect that there is actually more code in this file that should
> >> >> not be provided without CONFIG_FS_IOMAP even though we don't get a warning
> >> >> for it, and that we actually want a different rework, so please treat this
> >> >> as a bug report. I have applied the patch locally in my randconfig build
> >> >> setup to avoid seeing the warnings.
> >> >>
> >> >> Fixes: 5ac65736f740 ("dax: rip out get_block based IO support")
> >> >> Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx>
> >> >
> >> > Thanks for the report. I think the right way to deal with this is to just
> >> > select FS_IOMAP when we pull in the DAX code. I sent out a patch last week
> >> > that does this:
> >> >
> >> > https://lkml.org/lkml/2016/11/23/591
> >>
> >> It seems awkward for both filesystems and the FS_DAX core to be
> >> selecting FS_IOMAP. In the end FS_DAX and FS_IOMAP are both libraries
> >> of functionality that a filesystem can optionally use. I think the
> >> longer term FS_DAX stops being an independent user visible setting and
> >> is instead selected by filesystems that want DAX.
> >
> > This doesn't make sense to me. DAX is a user-selectable option that changes
> > behavior (at the user's request), but FS_IOMAP is a library of functionality
> > that is required for XFS and for DAX.
> >
> > The filesystems can all work fine without DAX (hence the user option), but DAX
> > and XFS at least require FS_IOMAP to behave correctly.
> >
> > If you made DAX a FS selectable option instead of a user selectable one, when
> > would a FS know it needs to include DAX support?
>
> With a user-selectable DAX knob per-filesystem, XFS_DAX, EXT4_DAX, etc...
That's just silly. Requiring users to configure every filesystem
that can support DAX to support DAX at config time is unneeded
config space bloat. DAX has an iomap config dependency, so just
select it when DAX is selected - everything else should just be
automatically and nobody else needs to care what build dependencies
DAX has.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
