Re: [RFC]: 64 bit LUN/Tags, dummy device in host_queue, host_lock <-> LLDD reentrancy

Re: [RFC]: 64 bit LUN/Tags, dummy device in host_queue, host_lock <-> LLDD reentrancy

[Aron Zeh]

> ARZEH@de.ibm.com said:
> > Does the use of driverfs-names mean that the HBA driver somehow comes
> > into the discovery-loop for devices (e.g. scan_scsis somehow interacts
> > with the HBA driver to determine which driverfs entry to create.)?
>
> Well, scanning is really only for legacy.  Way into the future, I'd like
to
> see hotplug notification for device attach events, so no fibre controller
ever
> need be troubled by the scan.  All they'd do is send a device attach
> notification into SCSI when they detect one.  (SCSI would probably then
turn
> around and ask for a REPORT_LUNS).

Blimey, that was a quick response. Only to spurn some more questions from
me though. Sorry.

If you say scanning is legacy only does that mean you expect it to be gone
by kernel 2.6?
I currently don't know of a way that SCSI devices (LUNs) generate hotplug
notifications by. (FC sends RSCNs and other nasty stuff for ports, which
are one level higher up. I don't think reconfiguring the LUNs behind a port
would generate any message, would it?)
Even of messages are generated, they'd probably differ according to the
underlying hardware. Would HBA drivers have to catch them and use more
generic callbacks to tell the SCSI stack?

Cheers,
Aron

Re: [RFC]: 64 bit LUN/Tags, dummy device in host_queue, host_lock <-> LLDD reentrancy

[James Bottomley]

ARZEH@de.ibm.com said:
> If you say scanning is legacy only does that mean you expect it to be
> gone by kernel 2.6? 

Not unless someone else is working on it...We currently don't have any of the 
replacement infrastructure in place.  It also depends on projects outside SCSI 
(hotplug, driverfs, initramfs etc.).

> I currently don't know of a way that SCSI devices (LUNs) generate
> hotplug notifications by. (FC sends RSCNs and other nasty stuff for
> ports, which are one level higher up. I don't think reconfiguring the
> LUNs behind a port would generate any message, would it?) Even of
> messages are generated, they'd probably differ according to the
> underlying hardware. Would HBA drivers have to catch them and use more
> generic callbacks to tell the SCSI stack? 

There would have to be a generic notify mechanism implemented within SCSI.  
Probably via a skeleton Scsi_Device with attached driverfs entry passed up.  
These would then trigger the hotplug events so we get hotplug event 
consistency.

The idea is that this would occur at the PUN (device) level, not the LUN (you 
don't want 65,535 notifications for a large array...).  Once the device has 
been noticed, it's up to the hotplug system to do something (or even if it 
chooses, nothing) about the device (like probe its LUNs, etc.).

James

Re: [RFC]: 64 bit LUN/Tags, dummy device in host_queue, host_lock <-> LLDDreentrancy

[Luben Tuikov]

Aron Zeh wrote:
> 
> I currently don't know of a way that SCSI devices (LUNs) generate hotplug
> notifications by. (FC sends RSCNs and other nasty stuff for ports, which
> are one level higher up. I don't think reconfiguring the LUNs behind a port
> would generate any message, would it?)

Unit Attention condition should be generated.

Some (all?) transports allow for the target sending an asynchronous
message to the initiator, but in SAM-3, an initiator being
a real such and a target being a real target, the target is the passive
device and the initiator is the active one, thus Unit Attention
condition is generated (SAM-3, 5.8.5).

> Even of messages are generated, they'd probably differ according to the
> underlying hardware. Would HBA drivers have to catch them and use more
> generic callbacks to tell the SCSI stack?

Forget about HBAs. In order to get anything working it has to be
at SAM-3 level.

It's ok when we plug into the PCI bus, but what happens
when SAN box number XXXX comes up and you're connected to
the farm over with iSCSI. How are you to know?...

That is, we cannot assume that it's an HBA there anymore,
just as we stopped assuming that the HBA is SPI, some time ago.
(It could be FCP, iSCSI, etc.)

-- 
Luben

Re: [RFC]: 64 bit LUN/Tags, dummy device in host_queue, host_lock <-> LLDDreentrancy

[Aron Zeh]

> Aron Zeh wrote:
> >
> > I currently don't know of a way that SCSI devices (LUNs) generate
hotplug
> > notifications by. (FC sends RSCNs and other nasty stuff for ports,
which
> > are one level higher up. I don't think reconfiguring the LUNs behind a
port
> > would generate any message, would it?)
>
> Unit Attention condition should be generated.
>
> Some (all?) transports allow for the target sending an asynchronous
> message to the initiator, but in SAM-3, an initiator being
> a real such and a target being a real target, the target is the passive
> device and the initiator is the active one, thus Unit Attention
> condition is generated (SAM-3, 5.8.5).
>
That's exactly where my question comes in. How do we see that an
asynchronous
reconfiguration on unit level has taken place? Unit Attentions are only
reported
in piggy-back fashion on top of a command per the standard you quoted (if I
did not misread it).
If a unit was just added to the configuration (and holds "unit was just
powered on" attention)
then I cannot see how Linux could find out.

> > Even of messages are generated, they'd probably differ according to the
> > underlying hardware. Would HBA drivers have to catch them and use more
> > generic callbacks to tell the SCSI stack?
>
> Forget about HBAs. In order to get anything working it has to be
> at SAM-3 level.
>
> It's ok when we plug into the PCI bus, but what happens
> when SAN box number XXXX comes up and you're connected to
> the farm over with iSCSI. How are you to know?...
>
> That is, we cannot assume that it's an HBA there anymore,
> just as we stopped assuming that the HBA is SPI, some time ago.
> (It could be FCP, iSCSI, etc.)

So you're ruling out the use of transport specific hotplug notifications
like RSCN on FC?
I currently cannot quite see how this would work. Isn't there always the
need to interpret reconfigurations of the hardware used to transport SAM-3
data on a lower level? Or has SAM-3 some capabilites for doing just that
that I have missed?

Aron

> --
> Luben
> -

Re: [RFC]: 64 bit LUN/Tags, dummy device in host_queue, host_lock <-> LLDDreentrancy

[Luben Tuikov]

Aron Zeh wrote:
> 
> That's exactly where my question comes in. How do we see that an
> asynchronous
> reconfiguration on unit level has taken place? Unit Attentions are only
> reported
> in piggy-back fashion on top of a command per the standard you quoted (if I
> did not misread it).
> If a unit was just added to the configuration (and holds "unit was just
> powered on" attention)
> then I cannot see how Linux could find out.

Yes, we have a similar conundrum.

Well, a notification is needed just because the transport has to know
in order to process properly any resevations/etc.

But all this is transport specific and UA is what SAM-3 specifies
as per Target/Initiator architecture (client/server). (SAM-3, 4.6(.1)) 

This model is properly preserved in Linux by the Scsi_Host_Template.

> So you're ruling out the use of transport specific hotplug notifications
> like RSCN on FC?

Not really ``ruling out'', but you can notify of such an event by other
means.

> I currently cannot quite see how this would work. Isn't there always the
> need to interpret reconfigurations of the hardware used to transport SAM-3
> data on a lower level? Or has SAM-3 some capabilites for doing just that
> that I have missed?

SAM-3 doesn't provide for ``hotplugging''. It's the whole server/client
architecture.

Since a human/robot is doing the hotplugging, such events can be
notified of by other means.

-- 
Luben