OFFTOPIC: New MBR and partitioning standard?

[Dave Cinege]

Isn't it about time the x86 platform supported more then 4 'real' partitions?

I'm getting really sick of this limitation and was thinking of sitting down
with some peers, drafting a new extended MBR standard, then submitting it OS
vendors.

For instance, the first partition is (generally) started on the 65th sector.
That leaves 63 512byte sectors that are always free. Why not extend the normal
partition entires say 16 sectors (== about 512 16byte partition entires),
and reserve the remaining sectors for extended MBR code? (IE the code in
sector 0, hops to sector 18)

This would be very easy to implement and remain compatible with legacy OS's.
A boot manager (partition entry swapper) program could be used to move
'extended' entries in and out of the original sector 0 partition table
for the sake of further legacy OS compatibility.

Has any one ever attempted to have something like this implemented by OS
vendors? Any comments you'd like to make? (Please via private mail)

I'd like to get some initial response back on this idea, and if it is positive
I'll set up a mailing list/and or have some IRC meetings to discuss details.

-- 
http://www.linkscape.net/       Linkscape Internet Services   732-541-4214
http://www.linuxrouter.org/     Linux Router Project

At 19981216.11:59 Zulu, Mach 1 was broken with a 1.0080162GHz Dual CPU machine.
I'm the Degenerate Overclocker that did it.  http://www.psychosis.com/doa/

[Horst von Brand]

Dave Cinege <[e-mail]> said:
> Isn't it about time the x86 platform supported more then 4 'real'
> partitions?

That is just a DOS limitation, AFAIU. Linux is happy living completely in
"extended" partitions.
> I'm getting really sick of this limitation and was thinking of sitting down
> with some peers, drafting a new extended MBR standard, then submitting it OS
> vendors.

The current partition scheme allows for further partitions via the kludgey
"extended" stuff. You'd have to stay backwards-compatible there too... and
that gets just too painful: You'd have to record the other (>= 4)
partitions twice.

BTW, there are several decent partition layouts, f.ex. BSD. Linux just
doesn't use any of them on ia32 (at least by default) to be able to coexist
with DOS et al. On SPARC it uses Sun's partition scheme, etc. I suspect
this was one of the factors that made Linux the most popular free OS, not
one of the *BSDs.
-- 
Dr. Horst H. von Brand                       mailto:[e-mail]
Departamento de Informatica                     Fono: [phone]
Universidad Tecnica Federico Santa Maria              [phone]
Casilla 110-V, Valparaiso, Chile                Fax:  [phone]

[Taral]

On Sat, 06 Mar 1999, Dave Cinege wrote:
> Isn't it about time the x86 platform supported more then 4 'real' partitions?
>
> I'm getting really sick of this limitation and was thinking of sitting down
> with some peers, drafting a new extended MBR standard, then submitting it OS
> vendors.
>
> For instance, the first partition is (generally) started on the 65th sector.
> That leaves 63 512byte sectors that are always free. Why not extend the normal
> partition entires say 16 sectors (== about 512 16byte partition entires),
> and reserve the remaining sectors for extended MBR code? (IE the code in
> sector 0, hops to sector 18)

Why wait for general acceptance? An extension of this sort can be implemented
OS-by-OS, with non-compatible OS's using the old extended partition system.
Just put some kind of checksum and magic number in the extended MBR area :)

Taral

[Dave Cinege]

Taral wrote:
> Why wait for general acceptance? An extension of this sort can be implemented
> OS-by-OS, with non-compatible OS's using the old extended partition system.
> Just put some kind of checksum and magic number in the extended MBR area :)

A main point to this is better multiple OS interoperabilty. This is
not specifically about better use by Linux.

Example, and what finally got me to post this request:

sda1
BOOT partition. After having had it wiped out so much and dealing with 'too far
down the disk' bios retardation, I finally put boot managers, kernels, etc in
a small partition at the beginning of the disk.

sda2
DOS partition. For some reason I seem to need this time to time.

sda3
NT partition. After fighting with the fucking thing I finally gave it a primary
since it has a tendency to not boot when in a logical. 

sda4
Extended logical. And all my ext2 partitions.

Solaris. NO ROOM. It needs a primary.
FreeBSD. NO ROOM. It needs a primary.
etc, etc.

To clarifiy, understand that only a primary is a 'real' partition. An extended
DOS partition, is no different then UFS. IE a primary that is logically
subdivided.

When you create a logically subdivided partition, the entired area it
occupies is locked only for logical use. Any space freed up (unless at the very
end) can not be reallocted to another primary. Thus dealing only in primary
partitions is a much more flexable and efficient when it comes to changing
partitions on a 'live' machine.

Ideally we could start from scratch, rewrite the BIOS, and standardize the
allocation of small for all partitioning  and boot managment. We would then
have...a workstation.  : >

But the idea is to come up with SOMETHING that is easy to code, and slips
into most system will no effort, and that WILL BE adopted and implemented
by yo-yo's like Microsoft.

-- 
http://www.linkscape.net/       Linkscape Internet Services   732-541-4214
http://www.linuxrouter.org/     Linux Router Project

At 19981216.11:59 Zulu, Mach 1 was broken with a 1.0080162GHz Dual CPU machine.
I'm the Degenerate Overclocker that did it.  http://www.psychosis.com/doa/

[George Bonser]

On Tue, 9 Mar 1999, Dave Cinege wrote:
> But the idea is to come up with SOMETHING that is easy to code, and slips
> into most system will no effort, and that WILL BE adopted and implemented
> by yo-yo's like Microsoft.

Don't count on Microsoft accepting it unless it somehow excludes other
operating systems from the drives or they can make a bunch of money for
doing nothing off of it.

[Simon Richter]

On Sat, 6 Mar 1999, Dave Cinege wrote:
> Isn't it about time the x86 platform supported more then 4 'real' partitions?

Well, I'm not sure I need to install more than four legagy OSs at the same
time, so I think it's not that big an issue. :-)
> I'm getting really sick of this limitation and was thinking of sitting down
> with some peers, drafting a new extended MBR standard, then submitting it OS
> vendors.

Well, in fact you're free to partition the drives as you wish, as long as
your MBR supports it. If you're not using anything but Linux, you can
achieve the desired result by enabling RDB code on i386 platforms and
partition your HD with an RDB. If you still have Windows, then you will
have to keep a compatibility table, so you haven't really won anything, as
you will still have to express your table in the old-fashioned way.

   Simon

[Stefan Reinauer]

BTW: Welcome back, Dave. I hope this attempt of our project won't go the
same way as the last times :-) But I have some good news, coming in later
mails... :)))

On Sat, 6 Mar 1999, Dave Cinege wrote:
> Isn't it about time the x86 platform supported more then 4 'real' partitions?
> True..
> I'm getting really sick of this limitation and was thinking of sitting down
> with some peers, drafting a new extended MBR standard, then submitting it OS
> vendors.
> For instance, the first partition is (generally) started on the 65th sector.
> That leaves 63 512byte sectors that are always free. Why not extend the normal
> partition entires say 16 sectors (== about 512 16byte partition entires),
> and reserve the remaining sectors for extended MBR code? (IE the code in
> sector 0, hops to sector 18)
>
> This would be very easy to implement and remain compatible with legacy OS's.
> A boot manager (partition entry swapper) program could be used to move
> 'extended' entries in and out of the original sector 0 partition table
> for the sake of further legacy OS compatibility.

Hmm.. why invent the wheel new? We could let's say use the Amiga RDB
standard which allows nearly unlimited partitions by having data organized
in linked lists.
Or BSD Disklabel with it's 8 or 16 partitions
The advantage of this way would be that all Linux and *BSD systems, which
interpret disklabels themselves, would support new partitions at once and
you would not have to write any new fdisks or sth like that
> I'll set up a mailing list/and or have some IRC meetings to discuss details.

Hmm IRC is a good idea.. Do you think we should have an own IRC server or
use EFnet or IRCnet (I am on IRCnet all the time, so I'd vote for IRCnet,
but I don't really matter)

Regards,
  Stefan

-- 
SuSE GmbH                                       Can you afford *NOT*
Schanz�ckerstr. 10                                     to use Linux?
D-90443 N�rnberg                 	
Germany                         			AlphaPowered

[Matthew Sullivan]

Hi

Stefan Reinauer wrote:
> > I'll set up a mailing list/and or have some IRC meetings to discuss details.
>
> Hmm IRC is a good idea.. Do you think we should have an own IRC server or
> use EFnet or IRCnet (I am on IRCnet all the time, so I'd vote for IRCnet,
> but I don't really matter)

I run CMDnet, and it has a number of private servers linked (eg BT & Netscape
internal servers) we also have a few university servers, you are welcome to link an
'OpenBIOS' server to the net, and/or just use CMDnet... I for one use it, cause I
can no longer get a relyable connection to IRCnet.

Yours

Matthew

(/server irc.cmdnet.net 6667 for a random CMDnet server)