On Wed, Sep 18, 2019 at 10:52:28AM -0700, Darrick J. Wong wrote:
> TBH I've been wondering for a while now if it would make more sense to
> do this in iomap_apply (and the open-coded versions in dax.c):
>
> struct iomap srcmap = { .type = IOMAP_HOLE };
>
> in the iomap_apply function (and change the "if (!srcmap.type)" checks
> to "if (srcmap.type != IOMAP_HOLE)"). That would get rid of the weird
> situation where iomap.h doesn't define an iomap type name corresponding
> to 0 but clearly it has some special meaning because the iomap code
> changes behavior based on that.
>
> It also strikes me as weird that for the @imap parameter, type == 0
> would be considered a coding error but for @srcmap, we use type == 0 to
> mean "no mapping" but we don't do that for @srcmap.type == IOMAP_HOLE.
>
> I mention that because, if some ->iomap_begin function returns
> IOMAP_HOLE then iomap_apply will pass the (hole) srcmap as the second
> parameter to the ->actor function. When that happens, iomap_write_begin
> call will try to fill in the rest of the page from @srcmap (which is
> hole), not the @iomap (which might not be a hole) which seems wrong.
I've renumber IOMAP_HOLE and initialized all the maps to it, that seems
like a nice improvement.
> As for this function, if we made the above change, then the conditional
> becomes unneccessary -- we know this is a COW write, so we call
> xfs_bmbt_to_iomap on both mappings and exit. No need for special
> casing.
OTOH I can't really agree to this. We now do pointless extra work
for a common case, which also seems a little confusing. It also goes
again the future direction where at least for some cases I want to
avoid the imap lookup entirely if we don't need it.
