[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210823130248.GC15536@lst.de>
Date: Mon, 23 Aug 2021 15:02:48 +0200
From: Christoph Hellwig <hch@....de>
To: Dan Williams <dan.j.williams@...el.com>
Cc: "ruansy.fnst" <ruansy.fnst@...itsu.com>,
"Darrick J. Wong" <djwong@...nel.org>,
Christoph Hellwig <hch@....de>,
linux-xfs <linux-xfs@...r.kernel.org>,
david <david@...morbit.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux NVDIMM <nvdimm@...ts.linux.dev>,
Goldwyn Rodrigues <rgoldwyn@...e.de>,
Al Viro <viro@...iv.linux.org.uk>,
Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v7 7/8] fsdax: Introduce dax_iomap_ops for end of
reflink
On Fri, Aug 20, 2021 at 08:18:44AM -0700, Dan Williams wrote:
> I notice that the @iomap argument to ->iomap_end() is reliably coming
> from @iter. So you could do the following in your iomap_end()
> callback:
>
> struct iomap_iter *iter = container_of(iomap, typeof(*iter), iomap);
> struct xfs_inode *ip = XFS_I(inode);
> ssize_t written = iter->processed;
> bool cow = xfs_is_cow_inode(ip);
>
> if (cow) {
> if (written <= 0)
> xfs_reflink_cancel_cow_range(ip, pos, length, true)
> }
I think this might be ok for now (with a big comment). Willy's original
iomap iter series replaced the iomap_begin and iomap_end with a single
next callback that takes the iomap_iter, which would solve this issue.
My plan is to look into a series that implements this and sees if this
is indeed a net win.
Powered by blists - more mailing lists