On Mon, Apr 9, 2018 at 10:02 AM, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote: > > On 2018-04-09 02:17 AM, Hannes Reinecke wrote: >> >> On 04/09/2018 04:08 AM, Tim Walker wrote: >>> >>> On Fri, Apr 6, 2018 at 11:09 AM, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote: >>>> >>>> >>>> On 2018-04-06 02:42 AM, Christoph Hellwig wrote: >>>>> >>>>> >>>>> On Fri, Apr 06, 2018 at 08:24:18AM +0200, Hannes Reinecke wrote: >>>>>> >>>>>> >>>>>> Ah. Far better. >>>>>> What about delegating FORMAT UNIT to the control LUN, and not >>>>>> implementing it for the individual disk LUNs? >>>>>> That would make an even stronger case for having a control LUN; >>>>>> with that there wouldn't be any problem with having to synchronize >>>>>> across LUNs etc. >>>>> >>>>> >>>>> >>>>> It sounds to me like NVMe might be a much better model for this drive >>>>> than SCSI, btw :) >>>> >>>> >>>> >>>> So you found a document that outlines NVMe's architecture! Could you >>>> share the url (no marketing BS, please)? >>>> >>>> >>>> And a serious question ... How would you map NVMe's (in Linux) >>>> subsystem number, controller device minor number, CNTLID field >>>> (Identify ctl response) and namespace id onto the SCSI subsystem's >>>> h:c:t:l ? >>>> >>>> Doug Gilbert >>>> >>> >>> Hannes- yes, a drive system altering operation like FORMAT UNIT is >>> asking for a dedicated management port, as the NVMe folks apparently >>> felt. But what is the least painful endpoint type for LUN0? >>> >>> >> I would probably use 'processor device' (ie type 3) as it's the least >> defined, so you can do basically everything you like with it. >> Possibly 'Enclosure Services' (type 0x0d) works, too, but then you have >> to check with the SES spec if it allows the things you'd need. > > > Processor device type (0x3) please. Then you are only required to support > the mandatory commands in SPC and that is not many. And then nothing > precludes you from implementing Start Stop Unit, Sanitize and/or Format > Unit on it. And as I pointed out earlier, you could even throw in a > copy manager (see SPC). Also as far as I know Linux, FreeBSD and Windows > will leave a Processor device type LU alone and just have a SCSI > pass-through device attached to it, and that is exactly what you want. > By default only root/administrator can open those pass-through devices. > > If you chose SES type (0xd) then the Linux kernel ses driver (and the > FreeBSD equivalent) would attempt to attach to it before the user space > could countermand it (as things stand). And SES additionally makes the > SEND DIAGNOSTIC and RECEIVE DIAGNOSTIC RESULTS commands mandatory and > at least one diagnostic page (0x0) mandatory. If it doesn't supply > any other SES dpages then those two drivers are going to get pretty > confused (which would be a good test for them). Also it could get > confusing from an administration point of view. I'm guessing many of > these Multi-Actuator SAS HDDs will end up in big enclosures. And > those enclosures most likely would present a SES device. Multiple dummy > enclosures within a real enclosure will look strange (especially as > SES already has a concept of a sub-enclosure). > > Doug Gilbert > > I also believe the dual-actuator, or any significant HDD parallelism, would map well onto an NVMe target, or NVMe-oF behind nvmet. Maybe a lightweight virtual NVMe controller that would efficiently present the HDD logs/mode pages/etc via the admin queue and the LUNs as fixed namespaces...? Doug, I will flesh your three LUN idea out some more and send it up the flagpole over here. Thanks for the input. I'd like to have a conversation at LSFMM and maybe pull together a fairly well defined consensus recommendation. Is that possible? Can we schedule it? Best regards, -Tim
