Re: lots and lots of disks again

Kurt Garloff
2004-02-12T15:00:37Z

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

Hi Al Viro,

On Wed, Feb 11, 2004 at 10:53:48PM +0000, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Feb 11, 2004 at 02:29:33PM -0800, Andrew Morton wrote:
> > I was rather hoping that Al would follow up on his comments yesterday
> > actually.
>
> OK. Proposed "sparse" partition numbers are Bad Idea(tm), for the same
> reasons why 255.255.252.240 is not a good netmask for a subnet in class B.
> It might be possible to handle if we do a single ->probe() for entire
> major and put the smarts into it (about the only way to do that, actually),
> but we'll have a hell of time hunting down all places assuming that
> device number == first device number + partition number. Note that we
> are talking about late-boot code, fs/partition/*, anything that calls
> bdget_disk(), etc. _And_ unknown amount of userland code. And code that
> exports information to userland (e.g. /proc/paritions or sysfs per-disk
> subtrees).

OK, so let's scratch that from the proposal.

It means we won't get 64 partitions, but I don't think this an
important feature for many users. And it looks like we can't do
it in a sane way without breaking the old numbers any way.
And the breakage should be deferred to the /dev/disk change in
2.7, IMHO.

Let's just use
31 20 19 4 3 0
|--major--|---disk---|-part-|

Any problems with that?

I would have reserved 2 bits (19,18) in case somebody finds a way to
implement it in a sane way, but probably you're right and it's not
doable in a sane way. As long as we don't bump up the limit to more
than 256k disks, we do not run into conflicts anyway.

Expect a patch later.

> Unless somebody has a good idea of the modifications involved and is willing
> to describe them (_not_ on usual aeb level of handwaving, please), I consider
> that idea as non-feasible.

One could add a hook to gendisk, and do some translation from user-visible
device numbers to kernel device numbers. Thus only causing hacks at one
place ...

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 --]