On Mon, Apr 2, 2018 at 10:29 AM, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote: > On 2018-04-02 11:34 AM, Tim Walker wrote: >> >> 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. > > > Just to amplify the case against a FU or SAN being allowed at almost any > time from either storage LU irrespective of what the other was doing. > Imagine one initiator has some important data on one LU and has an > EXCLUSIVE ACCESS persistent reservation on it. Then another initiator > (e.g. on a different machine) sends a FU to the other LU which is > honoured, wiping the whole device. One unhappy customer .... > > Doug Gilbert Thanks, Doug. That is very clear, and I get it. We'll have a solution. Best regards, -Tim -- Tim Walker Product Design Systems Engineering, Seagate Technology (303) 775-3770
