Re: Seagate Flex SMR

[Damien Le Moal <dlemoal@kernel.org>]

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