[8337] in linux-scsi channel archive
Re: Problem
daemon@ATHENA.MIT.EDU (Dan Jones)
Thu Mar 9 13:08:04 2000
Message-ID: <38C7E56B.108D6D68@valinux.com>
Date: Thu, 09 Mar 2000 09:54:51 -0800
From: Dan Jones <djones@valinux.com>
MIME-Version: 1.0
To: Eric Youngdale <eric@andante.org>
Cc: linux-scsi@vger.rutgers.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Eric Youngdale wrote:
>
>
> > In terms of adding extra devs- this is a quantity only pertinent
> > for allocating extra space for loadable HBA rescans- this doesn't have
> > anything to do with boot time probing with static linking, or if it does,
> you
> > can always change the SD_EXTRA_DEVS to something reasonable (like 512).
>
> We still have an effective limit of 128 disks. 8 majors * 16
> disks/major.
>
> Now that devfs is in, I am wondering whether it would make sense to
> allow the disk driver to dynamically allocate as many majors as it needs
> above and beyond the 8 majors. All of the hardcoded assumptions about major
> numbers should be gone from ll_rw_blk.c. In there would be the nasty problem
> of somehow getting the /dev tree - with devfs, that becomes a non-issue as
> the /dev entries are automatically created.
>
> There is still a limit of 256 majors * 16 disks/major or 4096 disks (an
> over-estimate as some majors are unavailable). We won't worry about that
> for now... :-).
>
Just a comment that the GFS folks have spent the last two months
working with a system that had 64+ FC drives connected to 16
hosts. Essentially, each host saw a little under 70 SCSI devices.
Since the GFS guys have, up to this point, a habit of increasing
their testbeds by a factor of two...
Add my vote for dynamic allocation.
--
Dan Jones, Storage Engineer VA Linux Systems
V:(408)542-5737 F:(408)745-9130 1382 Bordeaux Drive
djones@valinux.com Sunnyvale, CA 94089
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
