From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Chandan Babu R <chandan.babu@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfs: don't extend the FITRIM range if the rt device does not support discard
Date: Tue, 20 Aug 2024 09:19:55 -0700 [thread overview]
Message-ID: <20240820161955.GF6082@frogsfrogsfrogs> (raw)
In-Reply-To: <20240819150804.GA17283@lst.de>
On Mon, Aug 19, 2024 at 05:08:04PM +0200, Christoph Hellwig wrote:
> On Mon, Aug 19, 2024 at 08:00:30AM -0700, Darrick J. Wong wrote:
> > > This works. OTOH it will break again with the zoned RT subvolume
> > > which can't support FITRIM even on devices that claim it. And for
> > > actual users that care (and not just xfstests) these kinds of hacks
> > > don't seem very palatable..
> >
> > What does discard do on a zoned device? Is that how you reset the write
> > pointer? And does that mean that either you tell the device to discard
> > everything it's written in a zone, or it will do nothing?
>
> On an actual zone device it will probably do nothing. But at least for
> NVMe the command used to implement discard is mandatory, so all
> devices will show support. We also support the zoned mode on
> conventional devices, but instead of through FITRIM we want to issue
> it instad of a zone reset when the whole rtg has been garbage collected.
>
> > Hmm. No manpage for FITRIM. Why don't we return the number of bytes
> > in the space map that we iterated as range.len? Or perhaps leave it
> > unchanged?
>
> The above would seem sensible. Not sure if we can still pull it
> off, though.
It seems to have survived testing on TOT overnight, so I'll bake it into
djwong-dev when I go through and remove the rtgroups/rtsb feature bits
today. And I guess the rtgroups xarray conversion too.
--D
next prev parent reply other threads:[~2024-08-20 16:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-16 8:18 fix FITRIM with non-discard capable RT device v2 Christoph Hellwig
2024-08-16 8:18 ` [PATCH 1/2] xfs: remove a stale comment in xfs_ioc_trim Christoph Hellwig
2024-08-16 8:18 ` [PATCH 2/2] xfs: don't extend the FITRIM range if the rt device does not support discard Christoph Hellwig
2024-08-16 21:50 ` Darrick J. Wong
2024-08-19 12:44 ` Christoph Hellwig
2024-08-19 15:00 ` Darrick J. Wong
2024-08-19 15:08 ` Christoph Hellwig
2024-08-20 16:19 ` Darrick J. Wong [this message]
2024-08-20 16:35 ` Christoph Hellwig
-- strict thread matches above, loose matches on Subject: below --
2024-08-14 4:23 [PATCH 1/2] xfs: remove a stale comment in xfs_ioc_trim Christoph Hellwig
2024-08-14 4:23 ` [PATCH 2/2] xfs: don't extend the FITRIM range if the rt device does not support discard Christoph Hellwig
2024-08-14 5:41 ` Darrick J. Wong
2024-08-14 5:48 ` Christoph Hellwig
2024-08-14 6:16 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240820161955.GF6082@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.