Re: [PATCH 2/3] xfs: go straight to real allocations for direct I/O COW writes

[Christoph Hellwig <hch@lst.de>]

On Tue, Jan 24, 2017 at 08:50:45AM -0500, Brian Foster wrote:
> Is this reproducible on the current tree or only with this patch series?

It's only reproducible with the series modified to your review comments.

> Also, shouldn't the end_io handler only remap the range of the write,
> regardless of whether the initial allocation ended up preallocating over
> holes or purely a shared range?

The end_io handler is caller for the whole size of the write.  That's
mostly because we don't have an object corresponding to a write_begin
call.

> Perhaps what you are saying here is that we have a single dio write that
> spans wider than a shared data fork extent..?

Yes.

> In that case, we iterate
> the range in xfs_reflink_reserve_cow(). We'd skip the start of the range
> that is a hole in the data fork, but as you say, the
> xfs_bmapi_reserve_delalloc() call for the part of the I/O on the shared
> extent can widen the COW fork allocation to before the extent in the
> data fork, possibly to before the start of the I/O. (Thus we end up
> allocating COW blocks over the hole anyways...).

The problem is the following.

We have a file with the following layout


HHHHHHHHHHHHDDDDDDDDDDDDDD

where H is hole and D is data.  The H to D boundary is not aligned
to the cowextsize.

The direct I/O code now does a first pass allocating an extent for
H and copies data to it.  Then in the next step it goes on to D
and unshares it.  It then enlarges the extent into the end of the
previously H range. It does however not copy data into H again,
as the iomap iterator is past it.  The ->end_io routine however
is called for the hole range, and will move the just allocated
rounding before H back into the data fork, replacing the valid data
writtent just before.