All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: "Matias Bjørling" <m@bjorling.me>
Cc: "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


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

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