From: Badari Pulavarty <pbadari@us.ibm.com>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Joel.Becker@oracle.com, <linux-kernel@vger.kernel.org>
Subject: Re: 64-bit kdev_t - just for playing
Date: Wed, 2 Apr 2003 09:31:38 -0800 [thread overview]
Message-ID: <200304020931.38671.pbadari@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0304021413210.12110-100000@serv>
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
On Wednesday 02 April 2003 04:18 am, Roman Zippel wrote:
> Hi,
>
> On Mon, 31 Mar 2003, Badari Pulavarty wrote:
> > I have been playing with supporting 4000 disks on IA32 machines.
> > There are bunch of issues we need to resolve before we could
> > do that.
> >
> > I am using scsi_debug to simulate 4000 disks. (Ofcourse, I had
> > to hack "sd" to support more than 256 disks).
>
> Could you please post your changes to sd.c and anything relevant to it?
> Thanks.
>
> bye, Roman
Roman,
Here is the patch for sd to allow more than 256 disks.
There are few issues with the patch that need to be resolved.
1) With the patch I get 16 bits for minor. Since 4 bits are used for
partition, we get 12 bits to represent disks. So each major can support
2^12 = 4096 disks. Disks 0 - 4095 are mapped to major=8,
disks 4096 - 8191 to major = 65 and so on..
This means ..
(i) I need to create nodes in /dev/ to match new <major, minor> for
these disks. Currently "mknod" is broken due to glibc issues with dev_t.
(ii) We need to worry about backward compatibility. For example:
17th disk used to have <65, 0>. Now its major, minor is <8, 256>.
So /dev/ entires need to be re-created to match these, everytime
you reboot 2.4/2.5 etc. Greg KH udev might fix this for us.
2) Do we still need 16 majors for disks ?
We could change my patch to work around major/minor assignment
issues and maintain backward compatibility.
Thanks,
Badari
[-- Attachment #2: sd.patch --]
[-- Type: text/x-diff, Size: 1353 bytes --]
--- linux/drivers/scsi/sd.c Thu Mar 20 15:06:00 2003
+++ linux.new/drivers/scsi/sd.c Fri Mar 21 11:50:54 2003
@@ -56,7 +56,9 @@
* Remaining dev_t-handling stuff
*/
#define SD_MAJORS 16
-#define SD_DISKS (SD_MAJORS << 4)
+#define SD_DISKS_PER_MAJOR_SHIFT (KDEV_MINOR_BITS - 4)
+#define SD_DISKS_PER_MAJOR (1 << SD_DISKS_PER_MAJOR_SHIFT)
+#define SD_DISKS (SD_MAJORS << SD_DISKS_PER_MAJOR_SHIFT)
/*
* Time out in seconds for disks and Magneto-opticals (which are slower).
@@ -1328,17 +1330,23 @@ static int sd_attach(struct scsi_device
sdkp->index = index;
gd->de = sdp->de;
- gd->major = sd_major(index >> 4);
- gd->first_minor = (index & 15) << 4;
+ gd->major = sd_major(index >> SD_DISKS_PER_MAJOR_SHIFT);
+ gd->first_minor = (index & (SD_DISKS_PER_MAJOR - 1)) << 4;
gd->minors = 16;
gd->fops = &sd_fops;
- if (index >= 26) {
+ if (index < 26) {
+ sprintf(gd->disk_name, "sd%c", 'a' + index % 26);
+ } else if (index < (26*27)) {
sprintf(gd->disk_name, "sd%c%c",
'a' + index/26-1,'a' + index % 26);
} else {
- sprintf(gd->disk_name, "sd%c", 'a' + index % 26);
- }
+ const unsigned int m1 = (index/ 26 - 1) / 26 - 1;
+ const unsigned int m2 = (index / 26 - 1) % 26;
+ const unsigned int m3 = index % 26;
+ sprintf(gd->disk_name, "sd%c%c%c",
+ 'a' + m1, 'a' + m2, 'a' + m3);
+ }
sd_init_onedisk(sdkp, gd);
next prev parent reply other threads:[~2003-04-02 17:22 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-31 23:41 64-bit kdev_t - just for playing Badari Pulavarty
2003-03-31 23:54 ` William Lee Irwin III
2003-03-31 23:55 ` Joel Becker
2003-04-02 12:18 ` Roman Zippel
2003-04-02 17:31 ` Badari Pulavarty [this message]
2003-04-02 22:03 ` H. Peter Anvin
2003-04-03 10:09 ` David Lang
2003-04-03 11:14 ` Lars Marowsky-Bree
2003-04-03 12:13 ` Roman Zippel
2003-04-03 13:37 ` Andries Brouwer
2003-04-03 14:01 ` Roman Zippel
2003-04-07 15:02 ` H. Peter Anvin
2003-04-07 20:10 ` Roman Zippel
2003-04-07 21:57 ` Roman Zippel
2003-04-07 22:43 ` Kevin P. Fleming
2003-04-08 15:22 ` Roman Zippel
2003-04-08 22:53 ` Werner Almesberger
2003-04-08 23:11 ` David Lang
2003-04-08 23:47 ` Werner Almesberger
2003-04-08 23:58 ` Kevin P. Fleming
2003-04-08 23:56 ` H. Peter Anvin
2003-04-08 23:06 ` Andrew Morton
2003-04-09 0:40 ` Roman Zippel
2003-04-09 1:02 ` Joel Becker
2003-04-09 1:25 ` Roman Zippel
2003-04-09 16:42 ` Roman Zippel
2003-04-09 0:21 ` Roman Zippel
2003-04-11 9:58 ` Pavel Machek
2003-04-08 15:29 ` Roman Zippel
-- strict thread matches above, loose matches on Subject: below --
2003-04-09 18:40 James Bottomley
2003-04-09 20:54 ` Roman Zippel
2003-04-10 2:19 ` James Bottomley
2003-04-10 12:47 ` Roman Zippel
2003-04-10 15:30 ` James Bottomley
2003-04-10 23:53 ` Roman Zippel
2003-04-11 0:01 ` David Lang
2003-04-11 0:17 ` Roman Zippel
2003-04-11 0:47 ` Joel Becker
2003-04-11 1:11 ` Roman Zippel
2003-04-09 18:36 Andries.Brouwer
2003-04-09 21:11 ` Roman Zippel
2003-04-01 18:32 Andries.Brouwer
2003-03-28 15:33 Andries.Brouwer
2003-03-28 15:49 ` Roman Zippel
2003-03-28 11:46 Andries.Brouwer
2003-03-28 11:57 ` Roman Zippel
2003-03-28 11:10 Andries.Brouwer
2003-03-28 11:36 ` Roman Zippel
2003-03-30 20:05 ` H. Peter Anvin
2003-03-30 20:13 ` Roman Zippel
2003-03-27 22:37 Andries.Brouwer
2003-03-27 22:55 ` Roman Zippel
2003-03-27 20:27 Andries.Brouwer
2003-03-27 22:12 ` Roman Zippel
2003-03-27 22:55 ` Alan Cox
2003-03-27 23:19 ` Roman Zippel
2003-03-27 23:48 ` Greg KH
2003-03-28 9:47 ` Roman Zippel
2003-03-28 18:05 ` Joel Becker
2003-03-28 18:48 ` Roman Zippel
2003-03-31 8:31 ` bert hubert
2003-03-31 8:52 ` Roman Zippel
2003-03-31 17:24 ` Joel Becker
2003-03-31 21:32 ` Roman Zippel
2003-03-31 22:18 ` Alan Cox
2003-03-31 23:42 ` Roman Zippel
2003-04-01 14:42 ` Alan Cox
2003-04-01 16:35 ` Greg KH
2003-04-02 13:02 ` Roman Zippel
2003-04-01 14:42 ` Alan Cox
2003-04-01 16:52 ` Christoph Hellwig
2003-04-01 21:59 ` H. Peter Anvin
2003-04-02 7:12 ` Christoph Hellwig
2003-04-02 7:22 ` H. Peter Anvin
2003-03-31 23:45 ` Joel Becker
2003-03-31 23:07 ` Joel Becker
2003-03-31 23:35 ` Roman Zippel
2003-03-27 1:09 Andries.Brouwer
2003-03-27 19:23 ` Roman Zippel
2003-03-30 20:10 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200304020931.38671.pbadari@us.ibm.com \
--to=pbadari@us.ibm.com \
--cc=Joel.Becker@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox