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.
Dave Cinege dcinege@psychosis.com 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.
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
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.
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.
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
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
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)
-
Dave Cinege -
George Bonser -
Horst von Brand -
Matthew Sullivan -
Simon Richter -
Stefan Reinauer -
Taral