All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Downing <bdowning@wolfram.com>
To: "Ian K. Erickson" <ian@ns0.ipeg.com>
Cc: linuxppc-user@lists.linuxppc.org, linuxppc-dev@lists.linuxppc.org
Subject: Re: 15 partitions max prob revisited
Date: Tue, 19 Jan 1999 16:07:52 -0600	[thread overview]
Message-ID: <199901192207.QAA08969@wolfram.com> (raw)
In-Reply-To: <Pine.LNX.3.96.990119114919.10611D-100000@ns1.ipeg.com>


On Tue, 19 Jan 1999 11:51:15 -0800 (PST), "Ian K. Erickson" writes:
 > On Tue, 19 Jan 1999, Brad Boyer wrote:
 > > No, this is a Linux problem.  You cannot have more than 15 partitions
 > > on a drive because there are not device numbers allocated for anything
 > > higher than partition number 15.
 > 
 > Not that know anything about it, but out of curiosity: couldn't you use
 > mknod to create >15 [hs]da's? Or could you recompile the kernal to allow
 > them?

No.  It works like this:

brw-rw----   1 root     wheel      8,   0 Sep 12  1994 /dev/sda
brw-rw----   1 root     wheel      8,   1 Sep 12  1994 /dev/sda1
brw-rw----   1 root     wheel      8,   2 Sep 12  1994 /dev/sda2
...
brw-rw----   1 root     wheel      8,  14 Sep 12  1994 /dev/sda14
brw-rw----   1 root     wheel      8,  15 Sep 12  1994 /dev/sda15

...so partition 16 would be major 8 minor 16, except:

brw-rw----   1 root     wheel      8,  16 Sep 12  1994 /dev/sdb
brw-rw----   1 root     wheel      8,  17 Sep 12  1994 /dev/sdb1
brw-rw----   1 root     wheel      8,  18 Sep 12  1994 /dev/sdb2

If we had more device nodes to play with, we could have devices that
work per SCSI id instead of the dynamically allocated ones we have now.
It's a huge pain when you remove a disk on a server and sdf-sdk fall
down to sde-sdj.  Or worse -- when a faulty disk falls off the chain,
and when the (unsupervised) machine reboots -- everything is mounted in
the wrong place!  :-)

-bcd
--
**               Brian Downing
**  UNIX Systems Administrator
**        bdowning@wolfram.com

[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

  reply	other threads:[~1999-01-19 22:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-01-19 15:00 15 partitions max prob revisited Keith Jacob
1999-01-19 10:33 ` Brad Boyer
1999-01-19 19:51   ` Ian K. Erickson
1999-01-19 22:07     ` Brian Downing [this message]
1999-01-20  3:43 ` Paul Mackerras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199901192207.QAA08969@wolfram.com \
    --to=bdowning@wolfram.com \
    --cc=ian@ns0.ipeg.com \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=linuxppc-user@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.