QoS Domains
A QoS domain is the mechanism used to access data within a SEF Unit. QoS domains are created within a virtual device, and it is possible to have multiple QoS domains sharing a single virtual device. When multiple QoS domains share a virtual device, they will draw from a common pool of super blocks. However a super block is never shared between QoS domains and so data for QoS domains will never be intermingled in a super block. When QoS domains share a virtual device, there is no hardware isolation between them, so die-time conflicts are possible. The scheduling and prioritization features of SEF are used to order I/O for shared virtual devices and to resolve these die-time conflicts (e.g., software-defined isolation/quality of service).
When a QoS domain is created, several parameters are specified to define the characteristics of the QoS domain, which will be discussed below. Upon successful creation of a QoS domain, a device node will be created in the operating system namespace corresponding to the newly created QoS domain. It has a capacity and quota. The capacity is storage reserved in the virtual device for use by the QoS domain. The quota is how much total storage can be assigned to the QoS domain. Initially the quota is set to the capacity, but both can be changed later using SEFSetQoSDomainCapacity. At boot time the SEF Unit driver will create device nodes for all QoS domains previously defined for the device. Device nodes for QoS domains may be used to enumerate existing QoS domains as well as to restrict access to/enforce ownership of a QoS domain. All user data access commands are issued against a QoS domain. Typically, a QoS domain will be used by a single application or Flash Translation Layer/block driver/key value driver. An example of how the virtual devices of a SEF Unit could be divided into QoS domains is shown in the following figure 5. A QoS domain is a logical construct that defines a capacity taken from its virtual device’s capacity. It also defines a quota that may exceed the capacity of the virtual device as shown with QoS domains three through four. A SEF Unit can have at most 65534 QoS domains defined. The actual limit depends on the specific hardware.
Figure 5: QoS Domain Example
Allocated super blocks are owned by only one QoS domain at a time and are never shared. Super blocks are allocated from a shared pool allowing for host-managed thin provisioning. A QoS domain can allocate super blocks until it hits its quota or the free pool is exhausted.
Creation-time Parameters
vdHandle: the handle to the virtual device the QoS domain will be created in.
QoSDomainID: an identifier that will later be used to specify the created QoS domain. This identifier must be unique across the entire SEF Unit. Valid IDs start at 1 and must be less than or equal to ‘maxQoSDomains‘ returned by SEFGetInformation.
flashCapacity: the number of 4KiB ADUs reserved for the QoS domain. It supplies a capacity and a quota. The capacity is subtracted from the available ADUs from the virtual device so must be less than the currently available ADUs.
pSLCFlashCapacity: the number of 4KiB pSLC ADUs reserved for the QoS domain. It supplies a capacity and a quota. The capacity is subtracted from the available pSLC ADUs from the virtual device so must be less than the currently available pSLC ADUs.
ADUIndex: this is the index into the ADUSize[] array in ‘SEFInfo‘ returned by SEFGetInformation to select the data and metadata sizes of an ADU.
api: this field specifies the API to be used for this QoS domain. Currently only the super block API is supported.
defectStrategy: Specifies how defective ADUs are handled by the QoS domain. The choices are Perfect, Packed or Fragmented. The Perfect strategy hides defective ADUs through overprovisioning and mapping. Capacity is reserved, and ADUs are remapped to provide static and consistent flash memory addresses with contiguous ADU offsets. Packed also hides defective ADUs presenting consistent flash memory addresses with contiguous ADU offsets, but the size of super blocks will shrink as the device wears. With the Fragmented strategy, the client is exposed to the device’s defect management. ADU offsets are non-contiguous, and super blocks will shrink in size as the device wears. Refer to Addressing Chapter for more details.
recovery: Specifies the error recovery strategy for this QoS domain.
encryption: specifies the key the QoS domain is to be encrypted with.
numPlacementIDs: specifies the number of separate, simultaneously opened super blocks that may be used by the QoS domain in auto allocation mode. It does not affect the number of manually opened super blocks, which instead depends on the device itself.
maxOpenSuperBlocks: this is the maximum number super blocks that can be open in a QoS domain. If less than numPlacementIDs it will be set to numPlacementIDs+2. This affects resource and memory usage in the device.
defaultReadQueue: specifies the default read queue to use for read I/O operations. This can be optionally overridden when submitting I/O to a QoS domain. Read queues are defined by the virtual device and shared by the QoS domains defined in the same virtual device.
weights: Specifies the default weights for erase and program.