Seagate Flex SMR

Seagate Flex SMR

[Noah Bergbauer]

Hello,

Seagate Flex SMR drives are an early generation of hybrid SMR (HSMR) 
drives with a configurable zone layout. There are three main challenges 
towards supporting this in the kernel:

1. Instead of CONV they use SEQ_OR_BEFORE (type 4) zones. These permit 
random writes below the write pointer, so once full they behave exactly 
like CONV.
2. In an (in my opinion rather questionable) attempt at backwards 
compatibility the drives camouflage themselves as non-ZBC. Their ZAC 
support can be detected from a special ATA log page but ZBC commands 
must be emulated via ATA PASS-THROUGH as a SAT may refuse zone commands 
on a non-ZBC drive.
3. The zone configuration works by reporting both SEQ_OR_BEFORE and 
SEQWRITE_REQ zones each for the entire disk, and then for each pair of 
overlapping zones only one of them can be active while the other one 
will be in the offline condition. Right now some parts of the kernel 
(e.g. btrfs) don't play well with offline zones.

I implemented all of this last year and in the end everything was 
working fine under btrfs. Now I would like to attempt to get this into 
the kernel. This would involve rewriting most of my patches from 
scratch. So before I invest a lot of time and effort into doing so, my 
question is: would you as the maintainer even be willing to accept these 
changes into the kernel?

Best,
Noah Bergbauer

Re: Seagate Flex SMR

[Damien Le Moal]

On 8/21/26 23:38, Noah Bergbauer wrote:
> Hello,
> 
> Seagate Flex SMR drives are an early generation of hybrid SMR (HSMR) 
> drives with a configurable zone layout. There are three main challenges 
> towards supporting this in the kernel:

"Flex SMR" is not referring to any standard feature. So it is hard to see what
you are talking about. In Linux, we support only drives that follow a standard,
so for HDDs, that is SPC/SBC/ZBC for SAS drives and ACS/ZAC for SATA.

> 1. Instead of CONV they use SEQ_OR_BEFORE (type 4) zones. These permit 
> random writes below the write pointer, so once full they behave exactly 
> like CONV.

Abbreviations do not make for an easy reading... I am assuming here that
SEQ_OR_BEFORE refers to the SOBR == "Sequential or before" zone type that is
defined as part of the ZBC/ZAC Zone Domains (ZD)/Zone Realms (ZR) feature set.
Right ?

> 2. In an (in my opinion rather questionable) attempt at backwards 
> compatibility the drives camouflage themselves as non-ZBC. Their ZAC 
> support can be detected from a special ATA log page but ZBC commands 
> must be emulated via ATA PASS-THROUGH as a SAT may refuse zone commands 
> on a non-ZBC drive.

This is not questionable. ZD/ZR drives advertise themselves as regular disks
with device type 0x0000 so that when they have all SOBR zones in Domain 0 (the
SOBR zones domain) active and written, they behave 100% like regular disks and
are backward compatible with regular disks.

For a ZD/ZR disk in such state, you can use any file system (BTRFS/XFS/ext4 or
whatever) as is without any patches. In the case of BTRFS and XFS, you can even
use them with the the zoned format enabled and setting the software zone size to
the actual device SOBR zone size to get things to align nively to zones (that is
not necessary really, but that will work without any patching).

> 3. The zone configuration works by reporting both SEQ_OR_BEFORE and 
> SEQWRITE_REQ zones each for the entire disk, and then for each pair of 
> overlapping zones only one of them can be active while the other one 
> will be in the offline condition. Right now some parts of the kernel 
> (e.g. btrfs) don't play well with offline zones.

No. That is not how it works, at least not without patches to the SCSI & ATA
layers. The reason is that ZD/ZR drives are backward compatible with regular
disks. So the READ CAPACITY command reports the size of domain 0 only (the SOBR
zones). The sequential zones are in domain 1, which is unreachable without
ignoring the capacity returned by the READ CAPACITY command, because domain 1 is
in the LBA space beyond the capacity of domain 0.

> I implemented all of this last year and in the end everything was 
> working fine under btrfs. Now I would like to attempt to get this into 
> the kernel. This would involve rewriting most of my patches from 
> scratch. So before I invest a lot of time and effort into doing so, my 
> question is: would you as the maintainer even be willing to accept these 
> changes into the kernel?

Unless you have a strong production/use case for this, it is a hard no for me.

The reason is that properly supporting the zone domains/zone realms feature is
*extremely hard*. This is full of gotcha and plenty of things will not be
backward compatible with pure SMR support that we have. E.g. SOBR and
conventional zones are very different before the SOBR zone is fully written.

If you want to run a file system in domain 0 only, simply activate all the SOBR
zones in domain 0, make sure the SOBR zones are all initialized (written) and
you are done: the drive in that state is equivalent to a regular disk and
everything will just work fine.

Best regards.

-- 
Damien Le Moal
Western Digital Research

Re: Seagate Flex SMR

[Noah Bergbauer]

> "Flex SMR" is not referring to any standard feature. So it is hard to see what
> you are talking about. In Linux, we support only drives that follow a standard,
> so for HDDs, that is SPC/SBC/ZBC for SAS drives and ACS/ZAC for SATA.

The specification can be found in T10/18-007r0. It's not exactly ZD/ZR 
as it seems to predate those standards, but it's close.

> Abbreviations do not make for an easy reading... I am assuming here that
> SEQ_OR_BEFORE refers to the SOBR == "Sequential or before" zone type that is
> defined as part of the ZBC/ZAC Zone Domains (ZD)/Zone Realms (ZR) feature set.
> Right ?

Right.

>> 3. The zone configuration works by reporting both SEQ_OR_BEFORE and
>> SEQWRITE_REQ zones each for the entire disk, and then for each pair of
>> overlapping zones only one of them can be active while the other one
>> will be in the offline condition. Right now some parts of the kernel
>> (e.g. btrfs) don't play well with offline zones.
> 
> No. That is not how it works, at least not without patches to the SCSI & ATA
> layers. The reason is that ZD/ZR drives are backward compatible with regular
> disks. So the READ CAPACITY command reports the size of domain 0 only (the SOBR
> zones). The sequential zones are in domain 1, which is unreachable without
> ignoring the capacity returned by the READ CAPACITY command, because domain 1 is
> in the LBA space beyond the capacity of domain 0.

You are correct of course. What I mean is that after activating some 
zones in domain 1 the resulting holes in domain 0 need to be handled, 
and one can not simply assume that the full capacity range is always 
usable. Naturally, the capacity also needs to be increased to cover both 
domains.

>> I implemented all of this last year and in the end everything was
>> working fine under btrfs. Now I would like to attempt to get this into
>> the kernel. This would involve rewriting most of my patches from
>> scratch. So before I invest a lot of time and effort into doing so, my
>> question is: would you as the maintainer even be willing to accept these
>> changes into the kernel?
> 
> Unless you have a strong production/use case for this, it is a hard no for me.
> 
> The reason is that properly supporting the zone domains/zone realms feature is
> *extremely hard*. This is full of gotcha and plenty of things will not be
> backward compatible with pure SMR support that we have. E.g. SOBR and
> conventional zones are very different before the SOBR zone is fully written.
> 
> If you want to run a file system in domain 0 only, simply activate all the SOBR
> zones in domain 0, make sure the SOBR zones are all initialized (written) and
> you are done: the drive in that state is equivalent to a regular disk and
> everything will just work fine.
To be clear, what I have implemented is all about running a filesystem 
in domain 1. And I want to push back a little on your claim that this is 
extremely hard, because in a handful of small patches totaling around 
500 lines of code I have found solutions for all of these challenges. I 
am running btrfs on the sequential zones and it passes every test I have 
thrown at it. I can show you the code if you like.

For example, SOBR zone support specifically turned out to be quite easy 
to implement in a backward compatible manner. I simply return true from 
bdev_zone_is_seq() because treating a SOBR zone as sequential is always 
safe. A SOBR-enabled filesystem can then query bdev_zone_is_sobr() to 
take advantage of random writes.

The use case is that these drives exist, they're out there, and with a 
little bit of kernel work we could squeeze a few extra terabytes out of 
each and every one of them by leveraging their SMR capabilities. That's 
a clear win to me. Yes, they don't entirely follow the latest standards, 
but to me this is no different than the many device-specific quirks 
already supported by the kernel. And apart from the Flex-specific 
discovery procedure, all of this work should be usable for supporting 
other ZR/ZD drives in the future.

Best,
Noah Bergbauer

Re: Seagate Flex SMR

[Damien Le Moal]

On 8/24/26 01:45, Noah Bergbauer wrote:
>> "Flex SMR" is not referring to any standard feature. So it is hard to see what
>> you are talking about. In Linux, we support only drives that follow a standard,
>> so for HDDs, that is SPC/SBC/ZBC for SAS drives and ACS/ZAC for SATA.
> 
> The specification can be found in T10/18-007r0. It's not exactly ZD/ZR as it
> seems to predate those standards, but it's close.

This document is a proposal, not a standard. Some aspects of it are likely
integrated in ZAC-2, but if the drives you are talking about do not follow this
standard, we cannot support them.

>> If you want to run a file system in domain 0 only, simply activate all the SOBR
>> zones in domain 0, make sure the SOBR zones are all initialized (written) and
>> you are done: the drive in that state is equivalent to a regular disk and
>> everything will just work fine.
> To be clear, what I have implemented is all about running a filesystem in
> domain 1. And I want to push back a little on your claim that this is extremely
> hard, because in a handful of small patches totaling around 500 lines of code I
> have found solutions for all of these challenges. I am running btrfs on the
> sequential zones and it passes every test I have thrown at it. I can show you
> the code if you like.

You are looking at this very narrowly. The simple fact that you now have a
drive that reports a capacity that is nearly twice what the drive can actually
store will likely cause lots of problems. Also, you may have patched BTRFS, but
what about XFS, zonefs, and device mapper (dm-zoned, dm-crypt, dm-linear,
dm-flakey, dm-error) ? All of these work with pure host-managed zoned drives,
and without patching will likely break with ZD/ZR disks. Hence my point that
supporting these drives correctly is absolutely not trivial.

-- 
Damien Le Moal
Western Digital Research

Re: Seagate Flex SMR

[Theodore Tso]

On Sun, Aug 23, 2026 at 06:45:49PM -0500, Noah Bergbauer wrote:
> > "Flex SMR" is not referring to any standard feature. So it is hard to see what
> > you are talking about. In Linux, we support only drives that follow a standard,
> > so for HDDs, that is SPC/SBC/ZBC for SAS drives and ACS/ZAC for SATA.
> 
> The specification can be found in T10/18-007r0. It's not exactly ZD/ZR as it
> seems to predate those standards, but it's close.

Flex SMR refers to an early Seagate proposal for something which we
pushed for at Google called Hybrid SMR.  (See the Disks for Data
Center Paper / Keynote from the FAST 2016 conference).  Western
Digital countered with something called the REALMS API, and this got
hashed out in the standards committee, with a resulting set of ZAC and
SBC commands which include "REPORT REALMS", "REPORT ZONE DOMAINS" and
"ZONE ACTIVATE".  The basic idea is that zones can be activated and
deactivated, and when a set of SMR zones is activated a portion of the
disk platter corresponding to a set of CMR zones might get
deactivated, such that the contents of the deactivated zones would be
lost, but all other parts of the disk would be unaffected.

It is a feature standardized in T10 and T13, but it's not particularly
popular.  HOWEVER, all disks purchased by Google have firmware which
support these commands, and we have multiple HDD vendors who are our
suppliers.  It had been our hope that other hyperscalers would find
this useful.  Unfortunately, the programming model was far too complex
for most HDD users, and so I wasn't aware of anyone other than Google
using it.

This has saved us a huge amount of storage TCO costs at Google, and it
is how I earned my promotion to Senior Staff Engineer.  So I can say
that it is a useful feature, and we're using it to this day.

> > The reason is that properly supporting the zone domains/zone realms feature is
> > *extremely hard*. This is full of gotcha and plenty of things will not be
> > backward compatible with pure SMR support that we have. E.g. SOBR and
> > conventional zones are very different before the SOBR zone is fully written.

Yes.  Zome Domains/Realms is a completely different model from the
traditional SMR, and I *knew* it would be very hard to get it
upstream.  Given that we were using a userspace Cluster Filesystem
(e.g, Colossus), we really didn't need kernel support, since we could
manage the CMR and SMR zones from userspace.

Unfortunately, some of our operational requirements meant that it
could never be fully compatible with SMR, since we wanted disks to be
compatible with traditional CMR disks from the factory, but we then
wanted to be able to dynamically convert portions of the disks back
and forth between SMR and CMR in a non-destructive fashion for the
portion of the platter that was not converted.  This was a key part of
the storage cost savings, and we were able to convince our HDD
suppliers to support us in the T10/T13 standards committees to produce
something that would meet our requirements.

> To be clear, what I have implemented is all about running a filesystem in
> domain 1. And I want to push back a little on your claim that this is
> extremely hard, because in a handful of small patches totaling around 500
> lines of code I have found solutions for all of these challenges. I am
> running btrfs on the sequential zones and it passes every test I have thrown
> at it. I can show you the code if you like.

The hard part is what do you do with the deactived zones in domain 0?
Attempts to read or write into the deactived zones will result in SCSI
errors, so making it work in a way that allows you to have some
percentage of your disk that has the IOPS-optimzied CMR volumes, or
the bytes-optimized SMR volumes is the tricky bit, especially if you
are trying to be backwards compatible with local disk file systems
using partitions.

I suppose if you only allow zone activation/deactivations to be done
only when partitions are created or removed, it could be made simpler,
but that removes a lot of the actual storage TCO advantage of Hybrid
SMR disks.  (We can perform the SMR<->CMR conversions while the disk
is serving as part of the Colossus cluster file system, and that was a
key requirement for how to justify the SWE investment of our Hybrid
SMR project, and my spending a lot of time travelling to T10 standards
meetings.  :-)

> The use case is that these drives exist, they're out there, and with a
> little bit of kernel work we could squeeze a few extra terabytes out of each
> and every one of them by leveraging their SMR capabilities. That's a clear
> win to me. Yes, they don't entirely follow the latest standards, but to me
> this is no different than the many device-specific quirks already supported
> by the kernel. And apart from the Flex-specific discovery procedure, all of
> this work should be usable for supporting other ZR/ZD drives in the future.

Oh, they are standardized, but it's just not a very commercially
successful standard.  (Sort of like Object Based Disks, except there
is a hyperscaler which is actually still using Zone Realm/Domain
disks, and in fact all disks purchased by that hyperscaler have the
feature.  So arguably more successful than OBD, but not as successful
as we had hoped.)

The surprising thing to me is that there are people outside of my
company who are interested.  You have to be running at a pretty large
scale before the Storage TCO benefits dominate the SWE investment
costs, and while I did try to get other hyperscalers interested, they
had already invested in alternative technologies, and so we weren't
able to lower our Hybrid SMR costs by making it a more commonly
demanded feature in the marketplace.

Cheers,

						- Ted

Re: Seagate Flex SMR

[Noah Bergbauer]

>> The specification can be found in T10/18-007r0. It's not exactly ZD/ZR as it
>> seems to predate those standards, but it's close.
> 
> This document is a proposal, not a standard. Some aspects of it are likely
> integrated in ZAC-2, but if the drives you are talking about do not follow this
> standard, we cannot support them.

The drives I am talking about (ST12000NM0558 to name a specific example) 
appear to follow this exact proposal. Obviously I am aware of the 
difference between a proposal and a standard.

For the purposes of the kernel block layer they implement ZAC-2. As I 
said before, the majority of this work is applicable to any 
standard-compliant ZD/ZR drive.

The only exception would be the Zone Activation Capabilities field, 
which is all zero here (because it didn't exist yet). Instead, the 
domains are discovered through a vendor specific log page. Is this not 
an acceptable quirk?

>> To be clear, what I have implemented is all about running a filesystem in
>> domain 1. And I want to push back a little on your claim that this is extremely
>> hard, because in a handful of small patches totaling around 500 lines of code I
>> have found solutions for all of these challenges. I am running btrfs on the
>> sequential zones and it passes every test I have thrown at it. I can show you
>> the code if you like.
> 
> You are looking at this very narrowly. The simple fact that you now have a
> drive that reports a capacity that is nearly twice what the drive can actually
> store will likely cause lots of problems. Also, you may have patched BTRFS, but
> what about XFS, zonefs, and device mapper (dm-zoned, dm-crypt, dm-linear,
> dm-flakey, dm-error) ? All of these work with pure host-managed zoned drives,
> and without patching will likely break with ZD/ZR disks. Hence my point that
> supporting these drives correctly is absolutely not trivial.
$ df -B GB /dev/sda
Filesystem     1GB-blocks    Used Available Use% Mounted on
/dev/sda          13694GB 13688GB       3GB 100% /mnt/a

This was btrfs running on the above-mentioned 12TB drive. It works and 
the capacity is correct. What am I missing?

I'm hacking on this in my spare time, so please, cut me some slack here. 
The current situation is that domain 1 is completely unusable for the 
kernel. I would like to make some small and incremental improvements, 
starting with zonefs and then btrfs (XFS didn't support zones at all 
when I originally wrote this!). Does it really make sense to block those 
just because it doesn't yet have all the bells and whistles that one 
might eventually wish for?

Best,
Noah Bergbauer