Re: delalloc and reflink fixes & tweaks

[Christoph Hellwig <hch@lst.de>]

On Tue, Sep 18, 2018 at 07:23:23AM +1000, Dave Chinner wrote:
> Do you have any numbers that demonstrate the performance impact of
> the preallocation change? We've always intended to fix this exposure
> issue as you've done, I'm just interested in the sort of impact it
> has (if any).

For the absolute worst case - completely random 4k writes to a sparse
file I see a slowdown of about 3%.  Which is less than the improvement
that we saw from removing buffer heads.

> Also, with this change to use unwritten extents for all delalloc
> extents, we can start doing speculative preallocation for writes
> into holes inside EOF without leaving uninitialised/unzeroed blocks
> laying around.

Careful.  We already have issues because delalloc blocks before EOF don't
ever get reclaimed.  This triggers up on xfs/442 with 1k blocksize for
me.  I actually have a fix for that now, but that will require dropping
one of the cleanup patches from this series, so expect a respin.

If we want to more generic preallocation I guess we should follow the
example of the COW direct I/O path and mark all preallocated extents
as unwritten - that way we know delalloc extents that have the unwritten
bit set can be safely reclaimed.  But that is more work than I want
to do for this merge window at least.

> Using spec.  prealloc for "extend-via-truncate,
> sequential write to fill hole" workloads would greatly benefit from
> that. Did you have any plans to look at that code?

Not anytime soon.