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: Hans Holmberg <hans.holmberg@wdc.com>,
	linux-xfs@vger.kernel.org, Carlos Maiolino <cem@kernel.org>,
	Dave Chinner <david@fromorbit.com>,
	Christoph Hellwig <hch@lst.de>,
	dlemoal@kernel.org, johannes.thumshirn@wdc.com
Subject: Re: [PATCH] xfs: always allocate the free zone with the lowest index
Date: Wed, 21 Jan 2026 08:16:19 +0100	[thread overview]
Message-ID: <20260121071619.GA11963@lst.de> (raw)
In-Reply-To: <20260120155329.GM15551@frogsfrogsfrogs>

On Tue, Jan 20, 2026 at 07:53:29AM -0800, Darrick J. Wong wrote:
> On Tue, Jan 20, 2026 at 09:57:46AM +0100, Hans Holmberg wrote:
> > Zones in the beginning of the address space are typically mapped to
> > higer bandwidth tracks on HDDs than those at the end of the address
> > space. So, in stead of allocating zones "round robin" across the whole
> > address space, always allocate the zone with the lowest index.
> 
> Does it make any difference if it's a zoned ssd?  I'd imagine not, but I
> wonder if there are any longer term side effects like lower-numbered
> zones filling up and getting gc'd more often?

ZNS SSDs have to do wear leveling by mapping from logical to physical
zones or even recombine the internal arrangement from NAND blocks to
zones.  The interface does not expose wear counters, and for modern NAND
the numbers might be different for different cells in the SSD anyway
and/or depend on various other things.  Even read disturb where frequent
reads require a rewrite is a very real problem now.

So in short: no.  That's probably the biggest difference between the
old Open Channel SSD concept and ZNS or other zoned interfaces, and
what makes using them directly from a normal file system feasible.


  reply	other threads:[~2026-01-21  7:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20  8:57 [PATCH] xfs: always allocate the free zone with the lowest index Hans Holmberg
2026-01-20 15:53 ` Darrick J. Wong
2026-01-21  7:16   ` Christoph Hellwig [this message]
2026-01-21  7:23   ` Hans Holmberg
2026-01-21  7:16 ` Christoph Hellwig
2026-01-21 12:24 ` Carlos Maiolino

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=20260121071619.GA11963@lst.de \
    --to=hch@lst.de \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=dlemoal@kernel.org \
    --cc=hans.holmberg@wdc.com \
    --cc=johannes.thumshirn@wdc.com \
    --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