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. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
