On Mon, 13 Mar 2000, Eric Youngdale wrote:
> You know, I just figured out how to get rid of SD_EXTRA_DEVS without
> having to fix all of the nasty locking problems. The reason it is easier
> with disks is that there are only 16 devices per major, and what I would end
> up doing is splitting the datastructures so that there is one array per
> major. Each time we allocate a new major, the new structures for each major
> would be allocated to allow enough room for a full 16 disks. If a new
> driver gets loaded and there are no free slots, we just allocate another
> major and size it to allow 16 more disks. All of the datastructures related
> to sizes and so forth wouldn't change - those would be per-major, and the
> pre-existing arrays for already allocated majors would stay where they are.
> We would just allocate new ones for the new major.
It turned out to be a little easier than I thought. As it turns
out we use a kdev_t that is 16 bits for all platforms. That simplified
the job a bit. Mind you, that is a limit that may come back to haunt
us...
Two major user-visible changes. SD_EXTRA_DEV is gone (no longer
needed), and secondly there is no fixed limit to the number of major
numbers that the SCSI disk driver will use. Well, let me take that back -
there are at most 256 major numbers, and when you use them all up you are
screwed. I don't know at what point the kernel will simply refuse to
allocate any more majors.
Anyways, I am enclosing lightly tested patches - this seems to
work in my testbed with 2041 disks. It ended up using 128 major numbers.
I also had to fix the name generation function to generate names like
"sdaaa", etc. The testbed is built into scsi_debug - if you load it you
get 4 hosts, each with 512 targets. On each host target 2 is a tape drive,
target 7 is for the "host" itself, and all of the other targets are disks.
As far as I can tell, devfs seems to handle all of these disks
without a problem. I am enclosing an ls-lR of my /dev/scsi directory.
The devfsd program on the other hand eventually died with a segmentation
fault while trying to populate /dev.
One other comment - I had rigged scsi_debug to simulate 512
targets - mainly to further test the changes to scsi_scan.c where I
widened the parameters for ID, LUN, etc. That part worked just fine. The
widening of the parameters is already in 2.3.99-pre1.
I believe that most of the SMP safety issues have been addressed
in these patches, but I need to think about it a bit before I can say for
certain. I haven't opened up any new ones that I know of.
I am enclosing my diffs as well as a ls-lR of /dev/scsi from
devfs. One issue turned up - the generics driver was registering all of
the devices, but the minor numbers were wrapping, and as a result some of
them were wrong. I fixed sg.c to stop registering devfs entries once we
have exhausted the minor numbers. Kind of a hack, but I wasn't sure what
else to do.
Why am I tossing this out now? I don't have enough confidence to
send this to Linus right now, esp now that we are gearing up for 2.4. No
matter what we end up doing, the changes need to be thoroughly tested if
they are going to be incorporated, however. Thus I am posting it with the
usual caveats about backing up your data before you try it. Once it has
been burned in and debugged we can see whether there is sufficient demand
to consider it for the 2.4 series - if not I will just hold onto it for
2.5.
-Eric
scsi.ls3.gz
scsidisk3.diff.gz
