On Sat, Mar 31, 2018 at 10:52 AM, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote: > On 2018-03-30 04:01 PM, Bart Van Assche wrote: >> >> On Fri, 2018-03-30 at 12:36 -0600, Tim Walker wrote: >>> >>> Yes I will be there to discuss the multi-LUN approach. I wanted to get >>> these interface details out so we could have some background and >>> perhaps folks would come with ideas. I don't have much more to put >>> out, but I will certainly answer questions - either on this list or >>> directly. >> >> >> Hello Tim, >> >> As far as I know the Linux SCSI stack does not yet support any SCSI >> devices >> for which a single SCSI command affects multiple (two in this case) LUNs. >> Adding such support may take significant work. There will also be the >> disadvantage that most SCSI core contributors do not have access to a >> multi- >> actuator device and hence that their changes may break support for multi- >> actuator devices. > > > Hmmm, INQUIRY (3PC bit) and REPORT LUNS seem to be counter examples to > Bart's assertion. Plus there are a more that tell you about things outside > the addressed LU, for example the SCSI Ports VPD page tells you about other > SCSI ports hence other LUs) on the current device. > > > From Tim's command list: > > Device level > ------------ > 0x0, 0x1: okay > 0x4 (Format unit): yikes, that could be a nasty surprise, accessing a file > system on the other LU and getting an error "Not ready, format in > progress"!! > 0x12: standard INQUIRY okay, VPD pages not so much LU id different; relative > port id, different; target port id different (at the least) > 0x1b (SSU): storage LUs need to know this model, otherwise the logic on > each LU could get into a duel: "I want it spun up; no, I want it spun > down ..." > 0x35, 0x37, 0x3b, 0x3c: okay > 0x48 (sanitize): similar to Format unit above > 0x91,0x4c,0x4d: okay > MODE SENSE/SELECT(6,10): depends on page, block descriptor needs to be > partially device level (since LB size may be changed by FU which is > device level) > rest of device level: okay or (I) don't know > 0xf7: READ UDS DATA, that's interesting, but proprietary I guess > > Perhaps you could add a rider on FU and SAN: they get rejected unless the > other storage LU is in (logical) spun down state. > > > LU specific > ----------- > all okay, I hoping READ(6,10,12,16,32) and their WRITE cousins will be > there also :-) Plus the TMF: LU reset > > Device or LU > ------------ > all okay > > > I'm intrigued by your 3 LU model. My wish list for that: > > LUN 0 would be processor device type (0x3) so it wouldn't confuse the > OS (Linux) that it held storage (READ CAPACITY is mandatory for PDT 0x0 > and cannot represent a 0 block LU) and you could pick and choose which > SCSI commands to implement on it. LUN 0 TUR could report what the spindle > was really doing, SSU could do precisely what it is told (and SSU on LUNs > 1 and 2 would be an "and" for spin down and an "or" for spin up). I've > got several boxes full of SAS cables and only one cable that I can think > of that lets me get to the secondary SAS port. So on LUN 0 you could have > a proprietary (unless T10 takes it on board) mode page to enable the user > to say which ports that LUNs 1 and 2 where accessible on. Obviously LUN 0 > would need to be accessible on both ports. [A non-accessible LUN would > still respond to INQUIRY but with a first byte of 07f: PDT=0x1f (unknown) > and PQ=3 which implies it is there but inaccessible via the current port.] > > A processor PDT opens up the possibility of putting a copy manager on > LUN 0. Think offloaded (from main machine's perspective) backups and > restores where LUN 1 or 2 is the source or destination. > > Enough dreaming. > > Doug Gilbert Thanks for all the input from everybody. I'll collate it for a meeting with our interface architect. Best regards, -TIm -- Tim Walker Product Design Systems Engineering, Seagate Technology (303) 775-3770
