Hi Pete,
On Sat, Jul 20, 2002 at 07:57:29PM -0400, Pete Zaitcev wrote:
> For those who do not follow, John Cagle allocated 8 more SCSI
> disk majors.
Have those officially been assigned to SCSI disks?
So disks 128 -- 255 have majors 128 thr. 135?
> Here's a patch to make use of them. I am not sure
> if we want a 2.5 version; it's going to be all devicefs anyhow...
I've written a patch for sd that makes the allocation of majors
dynamic. The driver just takes 8 at sd_init and further majors are
allocated when disks are attached. Which saves a lot of memory for
all the gendisk and hd_struct stuff in case you do not have a lot of
SCSI disks connected. The patch does support up to 160 SD majors,
though currently, it won't succeed getting more than 132 majors.
> It really is strange how many places know major assignments.
Indeed. I missed the sysrq stuff in my patch, BTW.
Do you have any idea why we can't just sync all mounted filesystems
in do_emergency_sync()? Or at least all that are backed by a real
device? The test for IDE and SCSI majors seems bogus to me. What
about DASD? LVM? EVMS? MD? Loop? NBD? DRBD? What's the rationale
of restricting the sync to only IDE and SCSI? Deadlock avoidance?
> I hope I found all of them which matter. Also, I think nobody
> uses min_major/max_major, do you guys know if that's right?
It's right. Kill them! I killed them as well in my patch.
> More comments?
I'm gonna post my patches tomorrow ...
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security
> Date: Mon, 22 Jul 2002 19:08:40 +0200
> From: Kurt Garloff <[email protected]>
> > For those who do not follow, John Cagle allocated 8 more SCSI
> > disk majors.
>
> Have those officially been assigned to SCSI disks?
> So disks 128 -- 255 have majors 128 thr. 135?
I do not understand what your problem is. Do you refuse to recognise
John as the LANANA chair or something?
My patch is done in accordance with this:
http://www.lanana.org/docs/device-list/devices.txt
> > Here's a patch to make use of them. I am not sure
> > if we want a 2.5 version; it's going to be all devicefs anyhow...
>
> I've written a patch for sd that makes the allocation of majors
> dynamic. The driver just takes 8 at sd_init and further majors are
> allocated when disks are attached. Which saves a lot of memory for
> all the gendisk and hd_struct stuff in case you do not have a lot of
> SCSI disks connected. The patch does support up to 160 SD majors,
> though currently, it won't succeed getting more than 132 majors.
That's wonderful, but we cannot ship that. There is no userland
support to create device nodes in dynamic fashion and to ensure
that they do not conflict. This is why Arjan filed for and received
additional majors. Dynamic solutions need some time to float about
the community, I think.
BTW, DASD does the same thing already. I never saw any memo or document
explaining how to use this capability properly. Perhaps SuSE people
support it. Kurt, can you tell anything about it?
> Do you have any idea why we can't just sync all mounted filesystems
> in do_emergency_sync()?
> DASD? LVM? EVMS? MD? Loop? NBD? DRBD? What's the rationale
> of restricting the sync to only IDE and SCSI? Deadlock avoidance?
I suspect it is a deadlock prevention thing, too. I cannot say if
it ever worked satisfactory... :)
> I'm gonna post my patches tomorrow ...
Thanks, that's interesting. Like I said, they are not likely to
get to the distro soon, but I'd love to look at them.
-- Pete
On Mon, Jul 22, 2002 at 04:48:56PM -0400, Pete Zaitcev wrote:
> > I've written a patch for sd that makes the allocation of majors
> > dynamic. The driver just takes 8 at sd_init and further majors are
> > allocated when disks are attached. Which saves a lot of memory for
> > all the gendisk and hd_struct stuff in case you do not have a lot of
> > SCSI disks connected. The patch does support up to 160 SD majors,
> > though currently, it won't succeed getting more than 132 majors.
>
> That's wonderful, but we cannot ship that. There is no userland
> support to create device nodes in dynamic fashion and to ensure
> that they do not conflict. This is why Arjan filed for and received
> additional majors. Dynamic solutions need some time to float about
> the community, I think.
I might be stupid, but it looks to me like we want both the new majors
and the kernel structs dynamically allocated when they get actually used..
Hi Pete,
On Mon, Jul 22, 2002 at 04:48:56PM -0400, Pete Zaitcev wrote:
> > From: Kurt Garloff <[email protected]>
>
> > > For those who do not follow, John Cagle allocated 8 more SCSI
> > > disk majors.
> >
> > Have those officially been assigned to SCSI disks?
> > So disks 128 -- 255 have majors 128 thr. 135?
>
> I do not understand what your problem is. Do you refuse to recognise
> John as the LANANA chair or something?
Strange. I was just asking. Why would you think I would be silly and
refuse to recognize somebody?
> My patch is done in accordance with this:
> http://www.lanana.org/docs/device-list/devices.txt
OK, I should have checked there before asking here, probably.
> > SCSI disks connected. The patch does support up to 160 SD majors,
> > though currently, it won't succeed getting more than 132 majors.
>
> That's wonderful, but we cannot ship that. There is no userland
> support to create device nodes in dynamic fashion and to ensure
> that they do not conflict.
There will be.
> This is why Arjan filed for and received
> additional majors. Dynamic solutions need some time to float about
> the community, I think.
I don't object to having some more static ones. Fewer users will need
userspace tools for handling the dev nodes then ;-)
And of course, I'll adapt my patch to grab the assigned ones before
the unknown ones ...
> BTW, DASD does the same thing already. I never saw any memo or document
> explaining how to use this capability properly. Perhaps SuSE people
> support it. Kurt, can you tell anything about it?
I don't know much about DASD. They allocate block majors dynamically
starting from 255 backwards as far as I know. So, dev nodes need to
be created dynamically, I guess.
> > Do you have any idea why we can't just sync all mounted filesystems
> > in do_emergency_sync()?
> > DASD? LVM? EVMS? MD? Loop? NBD? DRBD? What's the rationale
> > of restricting the sync to only IDE and SCSI? Deadlock avoidance?
>
> I suspect it is a deadlock prevention thing, too. I cannot say if
> it ever worked satisfactory... :)
Well, Alt-SysRq-S does work; but it obviously misses to sync a number
of filesystems.
> > I'm gonna post my patches tomorrow ...
>
> Thanks, that's interesting. Like I said, they are not likely to
> get to the distro soon, but I'd love to look at them.
Well, I would be astonished if you adopted before we do ;-)
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 Mon, Jul 22, 2002 at 09:57:00PM +0100, Christoph Hellwig wrote:
> I might be stupid, but it looks to me like we want both the new majors
> and the kernel structs dynamically allocated when they get actually used..
Sure. The sd dynamic major allocation uses the registered block majors first.
Regards,
--
Kurt Garloff <[email protected]> Eindhoven, NL
GPG key: See mail header, key servers Linux kernel development
SuSE Linux AG, Nuernberg, DE SCSI, Security