| Message ID | 20241211085636.1380516-37-hch@lst.de (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [01/43] xfs: constify feature checks | expand |
On Wed, Dec 11, 2024 at 09:55:01AM +0100, Christoph Hellwig wrote: > While the zoned on-disk format supports reflinks, the GC code currently > always unshares reflinks when moving blocks to new zones, thus making the > feature unusuable. Disable reflinks until the GC code is refcount aware. This goes back to the question I had in the gc patch -- can we let userspace do its own reflink-aware freespace copygc, and only use the in-kernel gc if userspace doesn't respond fast enough? I imagine someone will want to share used blocks on zoned storage at some point. --D > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > fs/xfs/xfs_super.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index 59998aac7ed7..690bb068a23a 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -1818,6 +1818,13 @@ xfs_fs_fill_super( > goto out_filestream_unmount; > } > > + if (xfs_has_zoned(mp)) { > + xfs_alert(mp, > + "reflink not compatible with zoned RT device!"); > + error = -EINVAL; > + goto out_filestream_unmount; > + } > + > /* > * always-cow mode is not supported on filesystems with rt > * extent sizes larger than a single block because we'd have > -- > 2.45.2 > >
On Fri, Dec 13, 2024 at 03:12:47PM -0800, Darrick J. Wong wrote: > On Wed, Dec 11, 2024 at 09:55:01AM +0100, Christoph Hellwig wrote: > > While the zoned on-disk format supports reflinks, the GC code currently > > always unshares reflinks when moving blocks to new zones, thus making the > > feature unusuable. Disable reflinks until the GC code is refcount aware. > > This goes back to the question I had in the gc patch -- can we let > userspace do its own reflink-aware freespace copygc, and only use the > in-kernel gc if userspace doesn't respond fast enough? I imagine > someone will want to share used blocks on zoned storage at some point. I'm pretty sure we could, if we're willing to deal with worse decision making, worse performance and potential for deadlocks while dealing with a bigger and more complicated code base. But why?
On Sun, Dec 15, 2024 at 07:26:54AM +0100, Christoph Hellwig wrote: > On Fri, Dec 13, 2024 at 03:12:47PM -0800, Darrick J. Wong wrote: > > On Wed, Dec 11, 2024 at 09:55:01AM +0100, Christoph Hellwig wrote: > > > While the zoned on-disk format supports reflinks, the GC code currently > > > always unshares reflinks when moving blocks to new zones, thus making the > > > feature unusuable. Disable reflinks until the GC code is refcount aware. > > > > This goes back to the question I had in the gc patch -- can we let > > userspace do its own reflink-aware freespace copygc, and only use the > > in-kernel gc if userspace doesn't respond fast enough? I imagine > > someone will want to share used blocks on zoned storage at some point. > > I'm pretty sure we could, if we're willing to deal with worse decision > making, worse performance and potential for deadlocks while dealing with > a bigger and more complicated code base. But why? Mostly intellectual curiosity on my part about self-reorganizing filesystems. The zonegc you've already written is good enough for now, though the no-reflink requirement feels a bit onerous. But hey, it's not like I have numbers showing that a userspace copy-dedupe gc strategy is any better, so I'll not hold up this whole series on account of that. --D
On Tue, Dec 17, 2024 at 09:10:55AM -0800, Darrick J. Wong wrote: > Mostly intellectual curiosity on my part about self-reorganizing > filesystems. The zonegc you've already written is good enough for now, > though the no-reflink requirement feels a bit onerous. The no-reflink is mostly because we want a minimum viable merge candidate, and our initial uses for things like lsm databases and objects stores don't strongly need it. I hope to add reflink support ~ 2 or 3 merge windows after the initial code.
On Wed, Dec 18, 2024 at 08:09:34AM +0100, Christoph Hellwig wrote: > On Tue, Dec 17, 2024 at 09:10:55AM -0800, Darrick J. Wong wrote: > > Mostly intellectual curiosity on my part about self-reorganizing > > filesystems. The zonegc you've already written is good enough for now, > > though the no-reflink requirement feels a bit onerous. > > The no-reflink is mostly because we want a minimum viable merge candidate, > and our initial uses for things like lsm databases and objects stores > don't strongly need it. I hope to add reflink support ~ 2 or 3 merge > windows after the initial code. <nod> --D
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 59998aac7ed7..690bb068a23a 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1818,6 +1818,13 @@ xfs_fs_fill_super( goto out_filestream_unmount; } + if (xfs_has_zoned(mp)) { + xfs_alert(mp, + "reflink not compatible with zoned RT device!"); + error = -EINVAL; + goto out_filestream_unmount; + } + /* * always-cow mode is not supported on filesystems with rt * extent sizes larger than a single block because we'd have
While the zoned on-disk format supports reflinks, the GC code currently always unshares reflinks when moving blocks to new zones, thus making the feature unusuable. Disable reflinks until the GC code is refcount aware. Signed-off-by: Christoph Hellwig <hch@lst.de> --- fs/xfs/xfs_super.c | 7 +++++++ 1 file changed, 7 insertions(+)