| Message ID | 20241002150040.GB21853@frogsfrogsfrogs (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] iomap: don't bother unsharing delalloc extents | expand |
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. Looks good: Reviewed-by: Christoph Hellwig <hch@lst.de>
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: Reviewed-by: Brian Foster <bfoster@redhat.com>
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
On Wed, 02 Oct 2024 08:00:40 -0700, Darrick J. Wong wrote: > 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. > > Applied to the vfs.fixes branch of the vfs/vfs.git tree. Patches in the vfs.fixes branch should appear in linux-next soon. Please report any outstanding bugs that were missed during review in a new review to the original patch series allowing us to drop it. It's encouraged to provide Acked-bys and Reviewed-bys even though the patch has now been applied. If possible patch trailers will be updated. Note that commit hashes shown below are subject to change due to rebase, trailer updates or similar. If in doubt, please check the listed branch. tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git branch: vfs.fixes [1/2] iomap: don't bother unsharing delalloc extents https://git.kernel.org/vfs/vfs/c/f7a4874d977b [2/2] iomap: constrain the file range passed to iomap_file_unshare https://git.kernel.org/vfs/vfs/c/a311a08a4237
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;