zbc theory of operation

Hannes Reinecke hare at suse.de
Wed Aug 6 05:46:44 PDT 2014

* From the T10 Reflector (t10 at t10.org), posted by:
* Hannes Reinecke <hare at suse.de>
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