Re: lots and lots of disks again

Kurt Garloff
2004-02-10T11:04:21Z

[-- Attachment #1: Type: text/plain, Size: 4077 bytes --]

Hi Andrew,

On Wed, Feb 04, 2004 at 02:45:12AM -0800, Andrew Morton wrote:
> You can't hide from me you know ;)
>
> What to do about this?

Apply my patch ;-)

Find attached a patch that combines Badari's and Matthew's ideas.
It corrects the typos in Matthew's code snippets.

It does even address Christoph's criticism. Though I'm sure, he'll find
new points ...

> Last time it was discussed we had:
>
> Christoph Hellwig <hch@infradead.org> wrote:
> >
> >
> > - I think the bitmap overhead was killing us on big x86 machines, right?
> > so that might need some swork.

I limited the number of disks to 32k, which gives us a 4k bitmap.

Loading scsi_debug with 4k disks takes a minute or so, removing a few
minutes.
I doubt that it's caused by the bitmap, though. sg takes equally long.
Eventually, we'll need to ask oprofile.
As long as we know there are no holes, we could shortcut the bitmap
search ...

The patch would support up to 262144 disks, but I believe we're safe
with just 32k for the next years, even for those hard core multipath
people.

> > - a config option definitly is the wrong way to go.

There's no config option any more.
EMBEDDED -> 256
otherwise -> 32768

> > - I don't think assigning more numbers to the last major is a bad idea,
> > better assign them to the first one, maybe with a hole for what we're
> > using the other majors currently for, so when udev gets more mature
> > we can kill the additional majors.

Matthew stripes them over the majors. The first sixteen go to major0,
the next to major 1 ...; disks 256 -- 271 go to major0 again etc.

> Matthew Wilcox <willy@debian.org> wrote:
> >
> > LWN were kind enough to archive my previous thoughts on this at
> > http://lwn.net/Articles/54840/
> >
> > I'd've worked on some code for this if anyone had been interested ...

I've taken most from it.

I also let the support for two more partition bits in, though it
can't be really used at the moment. The genhd does not accomodate
non-contigous minors for partitions.

If the need arises, this can be done later, though it will be a bit
of a hack. So we can as well look at them as two reserved bits for now.

> badari <pbadari@us.ibm.com> wrote:
> >
> > I am not sorry for not replying for so long. I have been on vacation.
> >
> > 1) I am not really concerned about bitmap overhead. Bitmap of one
> > page (4k) - should be enough to support 32K disks. That should be
> > good enough for most of the machines.

Agreed.

> > 2) I used config option for 2 reasons
> > - to minimize impact on machines this is not needed.
> > - didn't want to depend on <major, minor> split to decide on
> > how many disks we can support.

That's why I made it depending on CONFIG_EMBEDDED.

> > 3) The reason, I assigned all the disks to last major is to maintain backward
> > compatibility with current major, minor assignments. Hopefully "udev"
> > will cleanup all these.

Matthew's approach does this as well.

> > My question is, what do we do for current 2.6 ? Hoping to address these
> > before distros start making 2.6 distros and adding their own stuff to support
> > this.
> >
> > And also, is there a plan to support more partitions per disk ?

There is, but either we have to hack gendisk or break the old numbering.
For now, I've done neither, but two bits are reserved for supporting 64
partitions per disk.

> And nothing happened.

Well, I even tested the patch.

I'm a bit worried that unloading scsi_debug with 4k disks takes so long,
but I doubt it's caused by sd, as it also happened with sg only.
For the rest, it survived well.

Note that sg currently limits the amount of generic devices to 8k.
We should probably also increase it to 32k.

If the sd patch is found acceptable, I'll submit a patch to sg.

Regards,
--
Kurt Garloff <garloff@suse.de> Cologne, DE
SUSE LINUX AG, Nuernberg, DE SUSE Labs (Head)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]