On Fri, Mar 08, 2013 at 05:49:11PM -0500, Lennart Sorensen wrote: > On Fri, Mar 08, 2013 at 04:34:28PM -0600, scame...@beardog.cce.hp.com wrote: > > I get ~4x the IOPSs with a block driver vs. scsi driver due to contention > > for locks in the scsi mid layer (in scsi_request_fn). It's the > > difference between the device being worth manufacturing vs. not. > > Well that starts to qualify as a good reason I suppose. Of course it > also makes you wonder if perhaps some work on optimizing that part of > the scsi stack is oin order (I have no idea if that's even plausible). > > > See this thread: http://marc.info/?l=linux-scsi&m=135518042125008&w=2 > > > > Driver is similar to nvme (also a new block driver), but this one is > > for SCSI over PCIe, basically highly parallelized access to very low > > latency devices and trying to use the SCSI midlayer kills the IOPS. > > Some nifty hardware that's for sure. > > > There were reasons back then for doing that one as a block driver > > which are no longer extant (hence the existence of the hpsa driver > > which supplanted cciss for new smart array devices.) > > > > All other things being equal, I would also prefer a scsi driver. > > Heck, it's called SCSI over PCIe -- I tried like hell to get it > > to perform adequately as a SCSI driver but all other things are > > not equal, not even close, the block driver was ~4x as fast. > > > > So we reluctantly go with a block driver, just like nvme did. > > Makes sense. Perhaps that does mean having to teach grub about it then.
We are not expecting to be able to boot from the device in the first iteration, so it's not as if we would need support instantly (not that I imagine we could get it instantly anyway), and it's not clear that it makes sense for such a high IOPS device to be used as a boot device in most imaginable use cases anyway, but OTOH, we would prefer not to rule out booting from it. So, that being said, are there any best practices for naming new block device nodes? Or is any scheme like /dev/sop[0-9a-z] about as good/bad as any other? And, is it a worthwhile idea to pursue adding some sort of shared device namespace for block devices to the kernel (maintaining backwards compatibility of device node names would of course be required) so that block devices could have some shared namespace as scsi devices do? Typically the block devices themselves don't care what the device nodes are named, only the userland apps do, though it falls to the block drivers to specify a device name via struct gendisk's ->disk_name member being set prior to calling add_disk(). If there were some kernel interface the block driver could use to get a disk name assigned from a shared name space, something like blk_get_new_disk_name(disk->disk_name); that could hand out device names like b%s, so you'd get all the block devices which use this interface having device names like /dev/bda, /dev/bdb, /dev/bdc, analogous to /dev/sda, /dev/sdb, etc. -- the specifics here don't matter to me, the above is just an idea off the top of my head -- then, we teach grub about this new block device namespace *once*, and force all new block drivers to use it. Thereafter, adding a block driver to the kernel causes no more grub related pain to grub and distro developers and users than adding a new scsi hba driver -- i.e. none. Would such a thing be worth pursuing? Or is there some good reason such a thing doesn't already exist? (Maybe this is more a question for lkml.) -- steve _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
