The current sd support for a scsi device probe with cache. If sd get no
response from a target during a probe inquiry, then sd will remember
that, and avoid additional calls to scsi_probe on non_zero LUNs on the
same target until the cache is cleared, while LUN0 of a target is always
probed. That's to say, sd driver may not try to enumerate every device
in sd.conf, which solved the problem that device probe extremly slow
when there are multiple LUNs per target.
For new SAN array, especially for Fibre channel array, the Fibre channel
children are self enumerated at runtime.
Thanks,
Nikko
Torrey McMahon wrote:
I'm hoping someone else jumps in on this one, because my memory is
shaky, but the bug in question was "sd driver tries to enumerate every
device in sd.conf". (Or something like that.) That was a while ago but
if you're using any recent Sun HBAs then you shouldn't have to put
anything in sd.conf which means, even if the issue is still there, you
wouldn't see it.
Vic Engle wrote:
Just a quick question. I recall in years past that if sd.conf was
pre-populated with entries that a boot time delay penalty would occur
which was supposed to be something like 3 seconds per lun for luns
that really weren't available.
My question is does solaris and the sd driver still behave this way?
With a modern SAN array this behaviour wouldn't make a lot of sense
because with the HBA logged in to the array port and bound to say scsi
target 80 the scsi layer on solaris could simply issue a report luns
command rather than probing for luns just because they were listed in
sd.conf.
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
