Hi Marcelo,
here comes patch 5/5 from a series of patches to support more than 128 (and
optionally more than 256) SCSI disks with Linux 2.4 by changing the sd driver
to dynamically allocate memory and register block majors as disks get
attached.
The patches are all available at
http://www.suse.de/~garloff/linux/scsi-many/
This patch is by far the largest and does implement the dynamic allocation
of block majors for the sd driver. This allows to support SCSI 256 disks
(with the officially assigned majors) and more (by using dynamic majors).
With this patch, sd allocates storage and registers majors only when disks
actually are attached. Therefore the braind^Wugly CONFIG_SD_EXTRA_DEVS
has died. Instead we register majors 8, then 65--71, then 128--135 (the
newly assigned majors), and then dynamically ask for new majors. For devfs
systems, devfs_alloc_major() is used, otherwise we use get_blkfops() to
probe for free block majors. (Note that get_blkfops() triggers kmod,
which means that we also avoid taking away majors from loadable modules.)
The driver tries 144--254 (which are not yet registered), and then the
possibly conflicting 72--127, 136--143, 12--64. Of course, you need some
userspace app parsing extended /proc/scsi/scsi (see patch 1/5) or
/proc/partitions to create the device nodes beyond disk 256. Theoretically,
you get up to 244 sd majors (3904 disks) supported this way.
The maximum number of majors that the driver takes is configurable
CONFIG_SD_MAX_MAJORS and defaults to 16. Which means that only the
officially assigned majors are used by default.
sd never frees majors, except on module unload. This simplifies locking in
the driver. This could be changed, though I doubt it's worth the trouble.
The patch does not rely on devfs and does not incur the prohibitive storage
requirements of the devfs-based sd-many patch.
There's not much more to say. Things that could be discussed is reuse
of detached slots (device numbers). Currently, we immediately recycle
them.
The sd driver has been cleaned up to support different number of partitions
per disk by changing a define. But it's set to 1<<4 of course. More a matter
of cleanliness ...
The patch also includes:
* an added field in gendisk, allowing some callback to map kdev_t to
device names. The corresponding change to fs/partitions/check has
been made. If more gendisk providers would fill in this fields,
the ugliness of disk_name() could be reduced significantly.
* a memset in IDE code (ide_probe.c:init_gendisk()), to avoid uninitialized
fields in the gendisk structure.
* Changes to is_local_disk() heuristics in sysrq.c. (Thanks to Pete Zaitvec
for inspiration!)
* a drives_dev function pointer in the scsi_device structure, that kills
the ugly min_major/max_major hack in scsi_lib.
* fixed the buffer legnth = allocation length doing the scsi_wait_req in
sd_init_onedisk(). (Thanks to Matt Darm for inspiration.)
Note that this patch should be complemented by a patch to sg to also allow
for more than 255 sg devices. I hope somebody will work on that.
Also note that a 2.5 port should be done ...
The patch is against 2.4.19-rc1 with patch 1/5 (and optionally 2--4)
applied. You will want to apply patch 4/5 (partition statistics) in order
to avoid significant consumption of memory when using many disks.
Marcelo, this patch is meant for inclusion into 2.4.20pre.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
On Fri, Jul 26, 2002 at 05:49:48PM +0200, Kurt Garloff wrote:
> The patch is against 2.4.19-rc1 with patch 1/5 (and optionally 2--4)
> applied. You will want to apply patch 4/5 (partition statistics) in order
> to avoid significant consumption of memory when using many disks.
Christoph Hellwig made me aware that the diff was not applying cleanly. Thx!
The reason was that I had the aa patches in my trees.
I rediffed against a clean rc3. New patches are available on
http://www.suse.de/~garloff/linux/scsi-many/
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security