zbc theory of operation
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
> model and the "Cooperatively Managed SMR" model described by Tim
> 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
> 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
REPORT ZONES command.
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
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
> 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
> LBA should be satisfied completely within the Host. In this way,
> (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