Re: [PATCH] xfs: handle large CoW remapping requests

[Christoph Hellwig <hch@infradead.org>]

On Tue, May 02, 2017 at 11:02:20AM -0700, Darrick J. Wong wrote:
> Nowhere, at the moment.  I had O_ATOMIC in mind for this though, since
> it'll call end_cow on the entire file at fsync time.  What if you've
> written 8GB to a file that you've opened with ATOMIC and then fsync it?
> That would trigger a remap longer than MAX_RW_COUNT which will blow the
> assert, right?

Yeah, good point.

> The current remapping mechanism only guarantees that whatever little
> part of the data fork we've bunmapi'd for each cow fork extent will also
> get remapped.  There isn't anything in there that guarantees a remap of
> the parts we haven't touched yet.  If one CoW fork extent maps to 2000
> data fork extents, we'll atomically remap each of the 2000 extents.  If
> we fail at extent 900, the remaining 1100 extents are fed to the CoW
> cleanup at the next mount time.  This patch doesn't try to change that
> behavior.

And that's perfectly fine, as long as we ensure after the mount time
cleanup everything is either remapped or not.

> Second half-baked idea: play games with a shadow inode -- allocate an
> unlinked inode, persist all the written CoW fork extents to the shadow
> inode, and reflink the extents from the shadow to the original inode.
> If we crash then we can just re-reflink everything in the shadow inode.

That was actually my very first implementation before reflink, and
using a swapext variant instead of reflinks.  Maybe it's actually better
in the end.