public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
	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: Mon, 19 Aug 2024 17:08:04 +0200	[thread overview]
Message-ID: <20240819150804.GA17283@lst.de> (raw)
In-Reply-To: <20240819150030.GO865349@frogsfrogsfrogs>

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.


  reply	other threads:[~2024-08-19 15:08 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 [this message]
2024-08-20 16:19           ` Darrick J. Wong
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=20240819150804.GA17283@lst.de \
    --to=hch@lst.de \
    --cc=chandan.babu@oracle.com \
    --cc=djwong@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox