Re: [PATCH 1/2] iomap: don't bother unsharing delalloc extents

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Oct 02, 2024 at 12:01:06PM -0400, Brian Foster wrote:
> On Wed, Oct 02, 2024 at 08:00:40AM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > If unshare encounters a delalloc reservation in the srcmap, that means
> > that the file range isn't shared because delalloc reservations cannot be
> > reflinked.  Therefore, don't try to unshare them.
> > 
> > Signed-off-by: Darrick J. Wong <djwong@kernel.org>
> > ---
> >  fs/iomap/buffered-io.c |    3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> > index 11ea747228aee..c1c559e0cc07c 100644
> > --- a/fs/iomap/buffered-io.c
> > +++ b/fs/iomap/buffered-io.c
> > @@ -1321,7 +1321,7 @@ static loff_t iomap_unshare_iter(struct iomap_iter *iter)
> >  		return length;
> >  
> >  	/*
> > -	 * Don't bother with holes or unwritten extents.
> > +	 * Don't bother with delalloc reservations, holes or unwritten extents.
> >  	 *
> >  	 * Note that we use srcmap directly instead of iomap_iter_srcmap as
> >  	 * unsharing requires providing a separate source map, and the presence
> > @@ -1330,6 +1330,7 @@ static loff_t iomap_unshare_iter(struct iomap_iter *iter)
> >  	 * fork for XFS.
> >  	 */
> >  	if (iter->srcmap.type == IOMAP_HOLE ||
> > +	    iter->srcmap.type == IOMAP_DELALLOC ||
> >  	    iter->srcmap.type == IOMAP_UNWRITTEN)
> >  		return length;
> >  
> > 
> 
> IIUC in the case of shared blocks srcmap always refers to the data fork
> (so delalloc in the COW fork is not an issue). If so:

Yep.

> Reviewed-by: Brian Foster <bfoster@redhat.com>

Thanks!

--D