Messages in this thread | | | Date | Mon, 8 Mar 1999 13:09:28 +0100 (MET) | From | (Guest section DW) | Subject | Re: OFFTOPIC: New MBR and partitioning standard? |
| |
From: Dave Cinege <dcinege@psychosis.com>
Isn't it about time the x86 platform supported more then 4 'real' partitions?
What a strange question. You can have two hundred partitions on a disk if you want. (For the default kernel the limit would be 63 on IDE, 15 on SCSI).
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.
Hmm. We support a handful of different partition types. If you invent one more, we might also support that. What is so very wrong about the present ugly system?
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)
With Linux you are free today to start the partition immediately after the MBR, and I generally do that. (However, this means that you cannot use OnTrack Disk Manager, or EZDrive etc. It also means that Partition Magic will be unhappy.) So, there is no reason to waste these sectors. However, this was more of an issue in the times of 20 MB disks. Today we have 20 GB disks, and wasting 32kB doesnt mean a thing. Having the BIOS remap your disk (with `LBA' or so) will on average waste a hundred times more.
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.
You can't be serious.
Andries
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |