Hi,
here comes patch 1/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 (1/5) does implement some infrastructure that is useful: We
extend the format of /proc/scsi/scsi to report the attached high-level
drivers.
This can be used by userspace applications to dynamically create device
nodes or to talk to the corresponding sg device (which otherwise is non-
trivial to find out!) and inquire extra information such as serial number
or WWID.
Here's a sample.
Host: scsi5 Channel: 00 Id: 04 Lun: 00
Vendor: Linux Model: scsi_debug Rev: 0003
Type: Direct-Access ANSI SCSI revision: 03
Attached drivers: sdr(b:41:10) sg18(c:15:12)
Patch is against 2.4.19rc1.
Marcelo, these patches are 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 11:50:27AM -0600, Andreas Dilger wrote:
> Actually, one interesting aspect of the EVMS vs. device-mapper argument
> going on that has totally been missed is that EVMS can do management of
> ALL disk block devices.
That's only natural as it try to duplicate the whole Linux block layer.
But it's everything but a good idea.
On Jul 26, 2002 18:54 +0200, Kurt Garloff wrote:
> On Fri, Jul 26, 2002 at 12:45:41PM -0400, Alexander Viro wrote:
> > On Fri, 26 Jul 2002, Kurt Garloff wrote:
> > > The patches are all available at
> > > http://www.suse.de/~garloff/linux/scsi-many/
> >
> > As long as you realize that it won't go in 2.5 in that form...
>
> The sd parts can and should be ported to 2.5, I think.
> The /proc/scsi/scsi extensions and other stuff I wrote to support it,
> won't be needed, as we have driverfs in 2.5.
> And, of course, the device number management will be solved in a more
> general way, but I do not yet see how.
Actually, one interesting aspect of the EVMS vs. device-mapper argument
going on that has totally been missed is that EVMS can do management of
ALL disk block devices.
At startup time it "consumes" all of the disk block devices in order to
generate the various mappings (LVM, RAID, etc) and at the end it spits
out the resulting devices as EVMS major devices. This includes devices
that have not been remapped, like hdXY or sdMN. EVMS has facilities
to ensure that devices get repeatable major/minor numbers if needed,
but they are allocated on an as-needed basis.
Currently EVMS only has a single major number, but it is my understanding
that they could easily take over all of the IDE and SCSI major numbers.
We would not have to worry about sparse device number allocation anymore,
and could have thousands of disks/partitions without any problems.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Hi Al,
On Fri, Jul 26, 2002 at 12:45:41PM -0400, Alexander Viro wrote:
> On Fri, 26 Jul 2002, Kurt Garloff wrote:
> > The patches are all available at
> > http://www.suse.de/~garloff/linux/scsi-many/
>
> As long as you realize that it won't go in 2.5 in that form...
The sd parts can and should be ported to 2.5, I think.
The /proc/scsi/scsi extensions and other stuff I wrote to support it,
won't be needed, as we have driverfs in 2.5.
And, of course, the device number management will be solved in a more
general way, but I do not yet see how.
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, 26 Jul 2002, Kurt Garloff wrote:
> Hi,
>
> here comes patch 1/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/
As long as you realize that it won't go in 2.5 in that form...
Hi Christoph, Andreas,
On Fri, Jul 26, 2002 at 06:55:45PM +0100, Christoph Hellwig wrote:
> On Fri, Jul 26, 2002 at 11:50:27AM -0600, Andreas Dilger wrote:
> > Actually, one interesting aspect of the EVMS vs. device-mapper argument
> > going on that has totally been missed is that EVMS can do management of
> > ALL disk block devices.
>
> That's only natural as it try to duplicate the whole Linux block layer.
> But it's everything but a good idea.
I won't go into that discussion ... Duplicating the Linux block layer is
certainly not such a good idea as the block layer is getting really nice
nowadays. But I have no idea to what extent something like this is done in
EVMS.
But the idea of having a number of majors assigned to disks, no matter what
the driver below is looks certainly like a good idea. With the current
approach, we'll need way too many majors, even if we'd have some more bits
in the future. Why not have a pool of disk majors and sd, hd, dasd, rd
(DAC960), the IDE-Raids, and ... allocate some of these as needed.
driverfs + some userspace tool will be needed to provide a consistent view
on them and to handle the permissions. Fortunately, disk devs tend to all
have the same perms, so we can start before this is addressed to its
full extent.
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 06:54:11PM +0200, Kurt Garloff wrote:
> Hi Al,
>
> On Fri, Jul 26, 2002 at 12:45:41PM -0400, Alexander Viro wrote:
> > On Fri, 26 Jul 2002, Kurt Garloff wrote:
> > > The patches are all available at
> > > http://www.suse.de/~garloff/linux/scsi-many/
> >
> > As long as you realize that it won't go in 2.5 in that form...
>
> The sd parts can and should be ported to 2.5, I think.
> The /proc/scsi/scsi extensions and other stuff I wrote to support it,
> won't be needed, as we have driverfs in 2.5.
> And, of course, the device number management will be solved in a more
> general way, but I do not yet see how.
Why that's quite simple (with apologies to South Park) :
1) finish the driver model code and banish devfs to a corner of
the kernel where it will not do any harm.
2) {silence}
3) Purely dynamic major and minors now work.
:)
It will happen, eventually. Most of us are busy laying the groundwork
right now...
thanks,
greg k-h
On Sat, Jul 27, 2002 at 12:32:24AM +0200, Kurt Garloff wrote:
> But the idea of having a number of majors assigned to disks, no matter what
> the driver below is looks certainly like a good idea. With the current
> approach, we'll need way too many majors, even if we'd have some more bits
> in the future. Why not have a pool of disk majors and sd, hd, dasd, rd
> (DAC960), the IDE-Raids, and ... allocate some of these as needed.
Linus wants this, and he stated that again on the kernel summit. But to do
this porperly (= not the EVMS way) it needs preparation. Al currently does
lots of work in that area to make the block drivers largely independent of
the major number. Once the drivers don't need the major number anymore
internally the only that needs sorting out is userlevel backwards-compatinlity.
I'm pretty sure the preparation will be finished for 2.6, also I can't comment
whether the unified disk major will be done. (Al?)
Hi Christoph, Al,
On Sat, Jul 27, 2002 at 10:41:19AM +0100, Christoph Hellwig wrote:
> On Sat, Jul 27, 2002 at 12:32:24AM +0200, Kurt Garloff wrote:
> Linus wants this, and he stated that again on the kernel summit.
I've not been there :-(
> But to do this porperly (= not the EVMS way) it needs preparation.
> Al currently does lots of work in that area to make the block drivers
> largely independent of the major number.
So he should port my sd patch to 2.5. All the data it uses is in a per-major
data structure. Currently, in most function it uses the kdev_t passed to find
the right pointer. But that's very easy to replace.
Of course, sd still assumes it gets a whole major and not parts of one. Other-
wise, more splitting would be needed.
> Once the drivers don't need the major number anymore
> internally the only that needs sorting out is userlevel backwards-compatinlity.
That takes more effort than the change itself, I guess.
> I'm pretty sure the preparation will be finished for 2.6, also I can't comment
> whether the unified disk major will be done. (Al?)
Would certainly be nice.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security