On 3/3/23 03:26, Bart Van Assche wrote: > On 3/1/23 18:03, Damien Le Moal wrote: >> But that is the issue: zones in the middle of each domain can be >> activated/deactivated dynamically using zone activate command. So there is >> always the possibility of ending up with a swiss cheese lun, full of hole of >> unusable LBAs because the other domains (other LUN) activated some zones which >> deactivate the equivalent zone(s) in the other domain. >> >> With your idea, the 2 luns would not be independent as they both would be using >> LBAs are mapped against a single set of physical blocks. Zone activate command >> allows controlling which domains has the mapping active. So activating a zone in >> one domains results in the zone[s] using the same mapping in the other domain to >> be deactivated. > > Hi Damien, > > Your reply made me realize that I should have provided more information. > What I'm proposing is the following: > * Do not use any of the domains & realms features from ZBC-2. > * Do not make any zones visible to the host before configuration of the > logical units has finished. Only make the logical units visible to the > host after configuration of the logical units has finished. Do not > support reconfiguration of the logical units while these are in use by > the host. > * Only support active zones. Do not support inactive zones. > * Introduce a new mechanism for configuring the logical units. That is not how the zone domains/zone realms feature is defined. Matching this would require specifications changes. But an even bigger problem is that this would not work for ATA drives (ZAC-2) as the concept of LUNs does not exist. > > This is not a new idea. The approach described above is already > supported since considerable time by UFS devices. The provisioning > mechanism supported by UFS devices is defined in the UFS standard and is > not based on SCSI commands. > > Bart. > -- Damien Le Moal Western Digital Research
