> > PV 660F and not seeing > 8 luns with 2.4.19-pre10.
> ^^^^^^^
>
> This device needs BLIST_LARGELUN.
I got that from your earlier post and addressed it directly. Thanks for
the pointer. I didn't know the 660 was defined explicitly in the
scsi_scan.c I've since recompiled several kernel versions to assert this
as being true with the BLIST_LARGELUN option and it's definitely fixed
my problems there.
> > I'll take a look at that, and see if I can merge it into -aa4.
>
> The patch should be in there, just not the additional devices that need
> BLIST_LARGELUN.
>
> > > The flag does allow a device to use more than 8 LUNs despite it reporting
> > > as SCSI Version 2 devices (which can not support more than 8 LUNs normally
> > > ...)
> > > The flag also needs to be set for some more devices, look for DGC, DELL, CMD
> > > and CNSi/CNSI devices that already have the BLIST_SPARSELUN flag.
> >
> > This would be a DELL device, so I'll see about changing it from
> > SPARESLUN to LARGELUN?
>
> No. Add " | BLIST_LARGELUN" .
Yep, Did that. Again Thanks!
> > > But as you did not post the output of /proc/scsi/scsi nor the syslog
> > > meesages from your SCSI subsystem nobody knows what devices you're using or
> > > what actually happens. Just speculations ...
> >
> > There's nothing to post from /proc/scsi/scsi or the syslog other than
> > there's no more than 8 devices on my FC chain. I guess the real point
> > here is that if you're using FC, you're probably going to use more than
> > 8 luns, even if not immediately. Especially for large Databases.
>
> People could have seen what SCSI device you're using.
> So I could have told you instead of guessing and risking to add to the noise
> myself.
I hear you loud and clear. I wouldn't have made so much noise myself had
it not been a *top* priority item that I couldn't find info on anywhere
else, plus the boss putting pressure too. Soon, this system will be a
6650 with PV 660F, 8GB RAM, using Linux with Oracle8.1.7.2, XFS, 0(1)
scheduler and nearly a TB of total DB.
I have some results from my benchmarking which are quite astounding too.
> Regards,
> --
> Kurt Garloff <garloff@suse.de> Eindhoven, NL
> GPG key: See mail header, key servers Linux kernel development
> SuSE Linux AG, Nuernberg, DE SCSI, Security
-- Austin Gonyou <austin@digitalroadkill.net> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/