zbc theory of operation

Ralph Weber Ralph.Weber at wdc.com
Wed Aug 6 07:09:13 PDT 2014

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <Ralph.Weber at wdc.com>
As I understand the theory, a host that does not want to participate in
operation of the ZBC device should require either Host Aware support or what
the cited article calls "drive-managed SMR", neither one of which forces the
host to know the full map at any time (including boot time). Of course, these
models include the potential for reduced read/write performance when the
drive is busy pounding the round peg in a square hole.
Disk manufacturers have every reason to expect extra effort from any host
that willingly picks the Host Managed ZBC model as a way to stabilized and/or
improve performance. Surely, the expected effort ought to reasonably include
maintaining a full zone map in at least the file system, even if doing so
increases the consumption of kernel memory. The tradeoff is between drive
resources and host resources, and additional resources means additional money
or time costs at either end of the wire. Yes, the old saw is true:
Nonetheless, a manufacturer of disk drives would be reckless if they totally
ignored boot time issues. This probably explains why all the disk
manufacturers of which I am aware are planning to build at least one product
where a Conventional Zone (see ZBC) occupies a suitably large number of LBAs
starting at LBA 0. Some are even planning to include only these Conventional
LBAs in the range of available LBAs returned by the READ CAPACITY command
(see SBC-4), but that is a different kettle of fish.
Regardless of the disk implementation details, the additional boot time
required to determine the size of the zero-based Conventional Zone will be
very small since almost no time is required to transfer the REPORT ZONES
information for a single zone that starts at LBA 0. Furthermore, the use of
LBA 0 as the Starting LBA for a REPORT ZONES command cannot possibly result
Having determined the size of the zero-based Conventional Zone, the host can
continue the booing process without further delays, using the established
size as the operational capacity of the disk. The work necessary to configure
the remainder of the disk can proceed in the background while other booting
activities continue unhindered.
To be sure, the zero-based Conventional Zone technique is not explicitly
described in ZBC. Since not all disks are boot disks, the T10 position is
that such a description is not appropriate normative content for ZBC. This
absence is expect to have no effect on disk manufacturers who want to sell
drives to the lucrative boot-device market.
All the best,
From: Hannes Reinecke [hare at suse.de]
Sent: Wednesday, August 06, 2014 7:46 AM
To: Ralph Weber; t10 at t10.org
Subject: Re: zbc theory of operation
On 08/05/2014 08:49 PM, Ralph Weber wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <Ralph.Weber at wdc.com>
> *
> Looking at this as a "theory of operation" question, may provide some
> The defined models for ZBC interactions are named:
> + Host Aware ...; and
> + Host Managed ...
> These names are intended to convey a design in which the Host is an
 > in whatever theory of operation might apply to the device types
defined in ZBC.
> In this regard, the ZBC operational theory lies in the vicinity of the
"Exposed SMR"
 > model and the "Cooperatively Managed SMR" model described by Tim
Feldman and
 > Garth Gibson in ;login volume for June 2013
> Taking a very small step away from this basic theory of ZBC operation one
 > the notion that the host is constantly aware of the organization
of the ZBC device.
 > Achieving this awareness can be summarized as involving three steps.
> 1) During the initialization of interactions with the device, the host
obtains a
 > local copy of the complete map of the device's organization using
the REPORT ZONES command.
> 2) As changes in the status of zones arise, the device notifies the host
 > the organization map local copy may need to be updated.
> 3) The host responds to such notifications with appropriately constructed
REPORT ZONES commands.
All agreed, and (probably not surprisingly) that's what I've tried
first. However, there is an issue with 1):
The data transfer of all zone information is required to take place
before the device can be used.
This requires a non-negligible amount of time, causing the system to
stall device access until all data is transferred. This might cause
issues if the device has to be initialized during system bootup.
Additionally it requires the host to set aside quite some (kernel-)
memory to hold the zone information, most of which will be used very
Hence it would be far more efficient to use a delayed allocation, ie
load the zone information only once an LBA is accessed.
That way one would
a) remove the stall during device initialisation
b) reduce the amount of memory consumed on the host
But to make this work one would be able to retrieve the zone
information for a given LBA; either by being able to calculate the
starting LBA directly or by being able to pass in any LBA to the
And, of course, 2) has the problem that unit attention codes are
neither mandated nor defined for a successful RESET WRITE POINTER
operation. Which would be required to maintain the local copy of the
zone information.
Rationale here is that a 'RESET WRITE POINTER' operation might be
injected from upper layers without the host necessarily be aware of
it. So to avoid deep packet inspection on every command being send
it would be preferable to require a unit attention code upon
successful RESET WRITE POINTER completion.
> In this interface, the presence of a Starting LBA field in the REPORT ZONES
 > command serves at least the following two purposes.
> * It allows a smaller buffer size to be used during the initialization
 > (see step 1), with repeated invocations of REPORT ZONES being
used until
 > the complete organizational map has been constructed.
> * It also allows a specific range of zones to be interrogated for status
 > updates in step 3).
> Since the ZBC theory of operation assumes that the Host is always aware of
 > complete organization map, the need to obtain information about a
specific single
 > LBA should be satisfied completely within the Host. In this way,
no overhead
 > (e.g., a command/response transaction between host and device) is
 > to answer the postulated question.
Yes, of course. With the delayed allocation scheme proposed above
the theory of operation wouldn't change. It would just be very
beneficial to system startup / device initialisation as we wouldn't
have to wait until all zone information is loaded.
Dr. Hannes Reinecke		      zSeries & Storage
hare at suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list