public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: "Matias Bjørling" <m@bjorling.me>
Cc: "Juhyung Park" <qkrwngud825@gmail.com>,
	"Niklas Cassel" <niklas.cassel@wdc.com>,
	"Damien Le Moal" <damien.lemoal@wdc.com>,
	daehojeong@google.com, linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	"Matias Bjørling" <matias.bjorling@wdc.com>
Subject: Re: [f2fs-dev] [PATCH 3/3 v2] f2fs: kill zone-capacity support
Date: Fri, 23 Feb 2024 09:38:15 -0800	[thread overview]
Message-ID: <ZdjYBwNTaxbZHpo4@google.com> (raw)
In-Reply-To: <65e03e4d-b7ef-27f9-2651-eac372f17a9b@bjorling.me>

On 02/22, Matias Bjørling wrote:
> On 21-02-2024 18:27, Jaegeuk Kim wrote:
> 
> > > Doesn't this break practically all ZNS NVMe devices?
> > 
> > Yes, so here I'm in questioning who is really using w/ zone capacity. If there's
> > no user complaining, I'd like to deprecate this, since this adds code complexity
> > and unnecessary checks.
> > 
> 
> Hi Jaegeuk,
> 
> I like to make a couple of points to hopefully keep the support in a little
> while longer.
> 
> - NVMe-based zone devices continue to be developed with the pow2 zone size
> and zone size != zone cap features. There was some divergence in the
> first-gen drives. However, all the second-gen drives I know of are
> implemented with those features in mind.
> 
> - A very active community is doing work using f2fs, and many of those
> members are working with the ZN540s device (which exposes a pow2 zone size).
> 
> - For drives with a capacity of less than 16TiB, f2fs is an excellent file
> system to use and is really useful for various use cases. We're using the
> f2fs daily for a couple of our workloads.
> 
> Work is ongoing on btrfs and XFS to support zoned storage devices, but they
> have yet to be through the trenches as much as f2fs has been with its zone
> support. So it would be great to have f2fs continue to support the pow2 zone
> sizes, as it is a valuable feature for the currently used and second-gen
> drives that have been released or are soon becoming available.
> 
> If there is a performance concern with the feature re: ZUFS, maybe the pow2
> implementation could be slightly more computationally expensive, as the
> feature, anyway, typically is used on more beefy systems.

Thanks, Matias for the background. It seems to be fair for keeping this for a
while tho, IMO, non-pow2 could address both parties.

> 
> Regards,
> Matias

  reply	other threads:[~2024-02-23 17:38 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-07  0:51 [PATCH 1/3] f2fs: deprecate io_bits Jaegeuk Kim
2024-02-07  0:51 ` [PATCH 2/3] f2fs: use BLKS_PER_SEG, BLKS_PER_SEC, and SEGS_PER_SEC Jaegeuk Kim
2024-02-07 23:51   ` [f2fs-dev] " Daeho Jeong
2024-02-12 18:10   ` [PATCH 2/3 v2] " Jaegeuk Kim
2024-02-20  7:30     ` [f2fs-dev] " Chao Yu
2024-02-20 20:33       ` Jaegeuk Kim
2024-02-21  1:04         ` Chao Yu
2024-02-20 20:39     ` [PATCH 2/3 v3] " Jaegeuk Kim
2024-02-21  1:30       ` [f2fs-dev] " Chao Yu
2024-02-21  1:54         ` Jaegeuk Kim
2024-02-21  2:17           ` Chao Yu
2024-02-07  0:51 ` [PATCH 3/3] f2fs: kill zone-capacity support Jaegeuk Kim
2024-02-07  2:42   ` Jaegeuk Kim
2024-02-07 22:27     ` [f2fs-dev] " Daeho Jeong
2024-02-07 23:29   ` [PATCH 3/3 v2] " Jaegeuk Kim
2024-02-07 23:51     ` [f2fs-dev] " Daeho Jeong
2024-02-20  9:48     ` Chao Yu
2024-02-20 19:01       ` Jaegeuk Kim
2024-02-21  8:14         ` Juhyung Park
2024-02-21 17:27           ` Jaegeuk Kim
2024-02-22 14:33             ` Matias Bjørling
2024-02-23 17:38               ` Jaegeuk Kim [this message]
2024-02-08  0:11 ` [f2fs-dev] [PATCH 1/3] f2fs: deprecate io_bits Daeho Jeong
2024-02-20  7:03 ` Chao Yu
2024-02-21 18:10 ` patchwork-bot+f2fs

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=ZdjYBwNTaxbZHpo4@google.com \
    --to=jaegeuk@kernel.org \
    --cc=daehojeong@google.com \
    --cc=damien.lemoal@wdc.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m@bjorling.me \
    --cc=matias.bjorling@wdc.com \
    --cc=niklas.cassel@wdc.com \
    --cc=qkrwngud825@gmail.com \
    /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