linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Kent Overstreet <kent.overstreet@linux.dev>,
	Viacheslav Dubeyko <slava@dubeyko.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	naohiro.aota@wdc.com, Matias.Bjorling@wdc.com,
	javier.gonz@samsung.com, bvanassche@acm.org, slava@dubeiko.com
Subject: Re: [LSF/MM/BPF TOPIC] : Current status of ZNS SSD support in file systems
Date: Tue, 16 Jan 2024 07:31:46 +0900	[thread overview]
Message-ID: <0e4ecb6c-dec8-414e-b55a-53478657c461@kernel.org> (raw)
In-Reply-To: <hqjm3bftitx2wpu74za4oq3sqifonpf7fc7mrwb4a7dbxzkm7h@stpm4dpahofc>

On 1/16/24 02:35, Kent Overstreet wrote:
> On Mon, Jan 15, 2024 at 11:22:36AM +0300, Viacheslav Dubeyko wrote:
>> Hello,
>>
>> I would like to suggest the discussion related to current
>> status of ZNS SSD support in file systems. There is ongoing
>> process of ZNS SSD support in bcachefs, btrfs, ssdfs.
>> The primary intention is to have a meeting place among
>> file system developers and ZNS SSD manufactures for sharing
>> and discussing the status of ZNS SSD support, existing issues,
>> and potential new features.
>>
>> The goals of the discussion are:
>> (1) share the current status of ZNS SSD support,
>> (2) discuss any potential issues of ZNS SSD support in file systems,
>> (3) discuss file system's techniques required for ZNS SSD support,
>> (4) discuss potential re-using/sharing of implemented logic/primitives,
>> (5) share the priliminary estimation of having stable ZNS SSD support,
>> (6) performance, reliability estimation comparing ZNS and conventional SSDs.
>>
>> Also, it will be great to hear any news from ZNS SSD vendors
>> related to new features of ZNS SSDs (zone size, open/active zone
>> limitation, and so on). Do we have any progress with increasing
>> number of open/active zones? Any hope to have various zone sizes, etc?
>>
>> POTENTIAL ATTENDEES:
>> bcachefs - Kent Overstreet
>> btrfs - Naohiro Aota
>> ssdfs - Viacheslav Dubeyko
>> WDC - Matias Bjørling
>> Samsung - Javier González
>>
>> Anybody else would like to join the discussion?
>>
>> Thanks,
>> Slava
> 
> There's also SMR hard drives to consider. For SMR, the much bigger zones
> means that we don't want to burn entire zones on the superblock (plural;
> we need two so that one will be alive while the other is being erased).

Hmmm... The zone size of SMR drives is actually much smaller than that of ZNS
drives: 256 MB vs over 1GB for ZNS. All host-managed SMR drives that I know of
use 256 MB zone size. One exception is 128 MB zone size that some user prefer
over the regular 256 MB. Depending on the drive, this can be changed with the
FORMAT WITH PRESET command, if the drive support that command of course.

btrfs superblock (and its copies) are handled as you describe: 2 zones per copy
used as a circular write ring. The write pointer location of the zones indicate
where the latest superblock is. Sure that wastes a little space. But that is not
much considering the total number of zones of a drive. The latest 28 TB SMR
drives have over 100,000 zones.

> We've got provisions for variable sized zones, are SMR hard drives doing
> anything with this? Or perhaps for a normal, random-overwritable zone at
> the start?

No, variable zone size is not a thing with SMR. bcachefs may support it, but in
general, that makes zone management much harder and the kernel does not allow
this (blk_revalidate_disk_zones() will return an error if it sees such drive).

Host managed SMR drives generally have a small number of conventional zones
(randomly writeable) at LBA 0. Generally about 1% of the total capacity/number
of zones, so about 1000 conventional zones. This is optional though but most
drives I know have that, except the special 128MB zone size one mentioned above
which is all SMR zones.

-- 
Damien Le Moal
Western Digital Research


  reply	other threads:[~2024-01-15 22:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-15  8:22 [LSF/MM/BPF TOPIC] : Current status of ZNS SSD support in file systems Viacheslav Dubeyko
2024-01-15 17:35 ` Kent Overstreet
2024-01-15 22:31   ` Damien Le Moal [this message]
2024-01-16  2:58 ` Bart Van Assche
2024-01-16  7:23   ` Viacheslav Dubeyko
2024-01-16 18:12     ` Jaegeuk Kim

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=0e4ecb6c-dec8-414e-b55a-53478657c461@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=Matias.Bjorling@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=javier.gonz@samsung.com \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=naohiro.aota@wdc.com \
    --cc=slava@dubeiko.com \
    --cc=slava@dubeyko.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;
as well as URLs for NNTP newsgroup(s).