On Wed, Oct 02, 2024 at 08:00:40AM -0700, Darrick J. Wong wrote: > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > 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@xxxxxxxxxx> > --- > 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: Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>
