From owner-freebsd-current Thu May 9 07:51:15 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA12668 for current-outgoing; Thu, 9 May 1996 07:51:15 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id HAA12658 for ; Thu, 9 May 1996 07:51:12 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id JAA00522; Thu, 9 May 1996 09:22:12 -0500 From: Joe Greco Message-Id: <199605091422.JAA00522@brasil.moneng.mei.com> Subject: Re: more than 32 scsi disks on a single machine ? To: bde@zeta.org.au (Bruce Evans) Date: Thu, 9 May 1996 09:22:11 -0500 (CDT) Cc: asami@cs.berkeley.edu, current@freebsd.org, nisha@cs.berkeley.edu In-Reply-To: <199605090313.NAA04873@godzilla.zeta.org.au> from "Bruce Evans" at May 9, 96 01:13:23 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Can we connect more than 32 disks on a single machine? I tried > > No. Hmm, considering I am halfway there on some machines, that seems an unfortunately low limit. > >Investigating further, I found this is in > > >#define makedev(x,y) ((dev_t)(((x) << 8) | (y))) /* create dev_t */ > > >So it seems like we're limited to 32 disks. > > This limits us to 16777216 disks, or only 8388606 disks if we avoid using > the high bit to avoid sign extension bugs. The limit is in dkunit() in > > > >Will really bad things > >happen if I try to change this? > > There are lots of things to change. The encoding would have to be really > ugly to preserve compatibility with existing device nodes. Hmm. What if we don't give a damn about existing device nodes? :-) "Take the plunge". I envision FreeBSD being used more and more in server class environments. I personally run several machines with three or four SCSI busses and more than DK_NDRIVE disks, and will be running even more in the near future. While I can live within the current constraints, I am feeling the tight belt. In particular, systems designed for high numbers of transactions per second will tend to have lots of smaller disks. I personally like to wire down drives: controller scbus0 at ncr0 disk sd0 at scbus0 target 0 unit 0 ... disk sd6 at scbus0 target 6 unit 0 controller scbus1 at ncr1 disk sd10 at scbus1 target 0 unit 0 ... disk sd16 at scbus1 target 6 unit 0 controller scbus2 at ahc0 disk sd20 at scbus2 target 0 unit 0 ... disk sd26 at scbus2 target 6 unit 0 controller scbus3 at ahc1 disk sd30 at scbus3 target 0 unit 0 disk sd31 at scbus3 target 1 unit 0 Now of course using this sort of "octal notation" is wasting some disk numbers, so I run out on the fourth bus, at sd31. Even using standard notation, I run out on the fifth bus. If I do not have 7 devices on a chain, I can "condense" further, but it becomes a confusing mishmosh to try to maintain. These are not problems for two or four drive systems. These become serious concerns when you're running sixteen drives though. I understand how this device node scheme came to be. I just happen to think that however and whenever possible, we should work to remove such constraints. :-) ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/546-7968