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.
Bart.
