On 8/13/19 9:19 PM, Douglas Gilbert wrote:
Bart Van Assche hinted at a better API design but didn't present it. If he did, that would be the first time an alternate API design was presented for async usage in the 20 years that I have been associated with the driver.
I would like to start from the use cases instead of the implementation of a new SG/IO interface. My employer uses the SG/IO interface for controlling SMR and HSMR disks. What we need is the ability to discover, read, write and configure such disks, support for the non-standard HSMR flex protocol, the ability to give certain users or groups access to a subset of the LBAs and also the ability to make that information persistent. I think that such functionality could be implemented by extending LVM and by adding support for all ZBC commands we need in the block layer, device mapper layer and also in the asynchronous I/O layer. The block, dm and aio layers already support submitting commands asynchronously but do not yet support all the ZBC commands that we use.
Are there any SG/IO use cases that have not yet been mentioned in this e-mail thread? If SMR and HSMR are the primary use cases for SG/IO, should asynchronous command support be added in the SG/IO layer or should rather ZBC support in the block, dm and aio layers be improved?
Thanks, Bart.
