On 8/16/19 8:59 AM, Douglas Gilbert wrote:
On 2019-08-15 1:30 p.m., Bart Van Assche wrote:
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.

I believe that you will find that the more layers of abstraction that are
placed between the actual device and the OS level API, the more difficult
the discovery process will be. And in some cases you will need to get to
a management layer to let those management functions "pass-through" those
layers. Some RAID card drivers take advantage of the no_uld_attach flag in
scsi_device to expose real devices, but only to the sg/bsg interface for
management purposes (for utilities like smartmontools) and do not produce
sd device nodes.

Isn't the very purpose of an operating system to provide device drivers and other abstraction layers such that not every application has to implement these?

My opinion is that using SG/IO to control SMR disks is suboptimal. A very powerful feature of the Linux block layer is the ability to stack block drivers. SG/IO is fundamentally incompatible with stacking block drivers. Stacking requires having access to the LBA, request size and other block layer request attributes. I don't think that we want to add code for parsing SCSI, NVMe pass-through commands etc. in block drivers as the device mapper.

Hence my proposal to improve support in the block layer for ZBC instead of using SG/IO to control SMR disks.


Reply via email to