On 8/28/23 20:55, Sam Li wrote:
>>> + /* close one implicitly open zones to make it available */
>>> + for (int i = s->zoned_header.zone_nr_conv;
>>> + i < bs->bl.nr_zones; ++i) {
>>> + uint64_t *wp = &s->wps->wp[i];
>>> + if (qcow2_get_zs(*wp) == BLK_ZS_IOPEN) {
>>> + ret = qcow2_write_wp_at(bs, wp, i, BLK_ZS_CLOSED);
>>
>> I'm wondering if it's correct to store the zone state persistently in
>> the qcow2 file. If the guest or QEMU crashes, then zones will be left in
>> states like EOPEN. Since the guest software will have forgotten about
>> explicitly opened zones, the guest would need to recover zone states.
>> I'm not sure if existing software is designed to do that.
>>
>> Damien: Should the zone state be persistent?
Yes and no. Yes you need to preserve/maintain zone states but not as is.
With a real drive, if you power cycle the device, you get the following states
changes:
Before | After power cycle
----------------+-------------------
EMPTY | EMPTY
FULL | FULL
IMP. OPEN | CLOSED
EXP. OPEN | CLOSED
CLOSED | CLOSED
READ=ONLY | READ-ONLY
OFFLINE | OFFLINE
So any open (implicit or explicit) zone will show up as closed after power
cycle. That is, the number of "active" zones does not change.
For the qcow2 emulation, as long as you do not also emulate read-only and
offline zones, you actually do not need to save the zone state in the zone
metadata. On startup, you can infer the state from the zone write pointer:
zone wp == zone start -> EMPTY
zone wp >= zone capacity -> FULL
zone wp > zone start -> CLOSED
And make sure that all closed zones are counted as the initial number of active
zones. The initial number of open zones will always be 0.
So it is easy :)
--
Damien Le Moal
Western Digital Research
