On Mon, Apr 9, 2018 at 10:02 AM, Douglas Gilbert <dgilb...@interlog.com> 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 <dgilb...@interlog.com> 
>>> 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
> 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

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,

Reply via email to