> Adaptec 2740 (the eisa one with dual channel) will boot from the lowest ...
This one probably isn't a serious problem, I imagine the driver could be
changed easily.
> Adaptec AHA 2920 (catually a Furure Domain controller) boots from the
> highest scsi id (which some may consider correct, since it is the
> highest priority device) but linux assigns scsi name starting from the
> lowest id found. Now try to put 2 disks in that box :(.
Wonderfull! I think this eliminates everything except big minors and
a partition device (and true LVM).
Then there's the problem with partitions, suppose you have an MBR with
a dos extended partition and a linux extended partition. It's possible
and very reasonable if you want to seperate the two chains. BUT suppose
you want to repartition the DOS chain, no problem the chains are seperate,
until linux counts the number of dos partitions and shifts all the linux
partitions up by one. :-(
This IMO eliminates a 32bit dev too (or at least makes the partition ID
about 16 bits long!)
IM(NV)HO A partition device would be the best, this is what I mean ...
Device major number 123 with 256 minors. (more majors for >256 parts)
The device is configured through the kernel command line or a /proc entry.
Config lines are of the form:
partition=0,ide,0x1f0,0,3
partition=1,aha1542,0x330,6,0x4032
These define:
/dev/part0 (123,0)
Use the ide driver hardware address 0x1f0, drive 0, MBR part 3
/dev/part1 (123,1)
Use the aha1542 driver HA 0x0330, drive (SCSI ID) 6, partition 2 on
the 3rd extended partition chained off of MBR part 4
/dev/root could be a symlink to /dev/part0 with part0 defined on the
lilo command line. The rest of the partitions are defined via the /proc
entry.
There would need to be another /proc entry, or unnumbered lines in the
normal one, which define the partitions that actually exist so an
installation program can notice and number any new partitions.
Config definitions would need to be checked by the kernel against existing
partitions and non-existent ones rejected.
This is a stable numbering scheme proof (I think) against any hardware
modifications that still allow boot. It'll allow boot off of a floppy,
provided the command line is saved, even if the BIOS can't boot the right
disk. It will also, correctly, fail if the root partition doesn't exist
or is changed.
Old partition numbers can be reused in a controlled manner.
Partitions can be re-numbered to any required scheme.
The scheme needs no major changes to minors (hmmm :-) )
Because the default is an empty (unnumbered) partition list possible
damage is limited.
If instead of using a physical partition number you use an offset and length
it would be possible to identify other (complex, rare and/or undocumented)
partitioning schemes in userspace. (Even on devices that aren't normally
partitioned; floppies, ramdisks, CDs ?)
If the partition numbers were initilised to values like '0x803' instead of
'undef' this could be interpreted as the current scheme for partition
numbers (ie a major and minor number). IMO this should only be done if
there's no 'partition=' item on the linux kernel cmd line.
This interface could probably be extended later to be the stabliser for
LVM support, say by adding a LVM id number somewhere.
And here are some 'Notes':
LILO would need to be told about this if /boot is to be on /dev/part4 (eg)
I've no idea how easy (or not) this is to do with the current Linux kernel.
-----------------------------------------------------------------------------
> 2) user space symlinks are usually a bad idea.
Agreed
> 3) devfs
I really dislike this, it feels a lot like putting /dev onto a ramdisk
with a special program to copy stuff from /proc and gives me a really
fragile feeling.
> 4) what could be done now
> ask Linus to add the new naming scheme BEFORE 2.2 (maybe code can be borrowed
> from devfs) we would need:
> 16 partitions per device x
Only 16? Did you know you can put 16 partitions directly into the MBR ?
(LILO doesn't understand it, but the kernel does.)
> 16 devs per channel x
Well, if anybody ever makes (has made?) an IBM-SSA driver for the PPC
port you'll need more. I think the default max is 48 drives but that's a
software limit.
IIRC, Firewire has the same 'problem'.
> 4 channels per controller x
> 8 controllers per machine (i saw 5 controllers on an HP server once) =
Probably ok, if you're really being silly you might have 2 software raid-5
devices with a controller for each disk, but I don't know where you'd plug
in 10 devices!
> 32 major number (we have more than 128 major block devices free)
Oops, I think I just filled it up with firewire :-) :-)
> this would leave the old (major 8) scsi disk for people who want the old
> behaviour and give some space for people that cannot just use it.
Ok, I'm probably being a bit silly, but this doesn't strike me as good even
for a stopgap measure. :-(
> 5) what could be done for 2.3
> since all that inodes are just stupid we could at least get done with the partitions
> a lvm is really becoming a necessary thing, then we could have disks (no matter if
> they are ide/scsi/xt disks or even md devices).
Just don't forget that it has to boot too :-)
Preferably without the rigramole needed for MD-root. :-(
Actually, what I've described probably _is_ the lowest level of a LVM,
constructed in such a way that it's useful on it's own; this leads to
the question - just what is the current status of a Linux LVM? Has any
significant work been done yet or is it just hot vapour like my message?
--
Rob. (Robert de Bath <http://www.cix.co.uk/~mayday>)
<http://poboxes.com/rdebath>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu