Re: [PATCH 12/19] xfs: fill out the srcmap in iomap_begin

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

 



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.



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux