On 2019-08-16 2:10 p.m., Bart Van Assche wrote:
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.
Please go right ahead. I just don't see why it should be at the expense
of this patchset or the sg pass-through in general.
Wearing another hat as the smartmontools SCSI maintainer, I know of no
supported OS or RAID product that has the infrastructure you talk about
for SMART information. The industry assumption seems to be that the
information will be pulled out at the real device level by a command set
pass-through. And RAID products present an issue if they don't support
a "no_uld_attach" type mechanism. The issue is that they then need to
offer a proprietary pass-through mechanism *** to bypass the virtual
device presented to the OS in order to get to the individual _real_
storage devices holding the SMART information. Sub-optimal maybe, but
still effective.
Doug Gilbert
*** and to their credit (IMO) several RAID "big boys" have sent the
smartmontools project working code to navigate their proprietary
pass-through mechanisms. Better that than us needing to beg for it.
