Partition tables and cylinder boundaries
- spix
- Member
- Posts: 128
- Joined: Mon Jun 26, 2006 8:41 am
- Location: Millicent, South Australia
- Contact:
Partition tables and cylinder boundaries
Hi,
I am in the process of writing an fdisk utility to modify partition tables.
I have an idea that partition must start and end on cylinder boundaries, is this correct? I'm a bit confused with the whole H/S/C part of the partition table. My OS doesn't use them, but I guess I need to put them in there for other OS?
So, I guess what I want to know is, a user can say they want partition 1 to start on sector X and end on sector Y, so long as they don't overlap with another partition, is there any other special checking I need to do on X and Y to make sure they are acceptable?
Thanks....
Andrew
I am in the process of writing an fdisk utility to modify partition tables.
I have an idea that partition must start and end on cylinder boundaries, is this correct? I'm a bit confused with the whole H/S/C part of the partition table. My OS doesn't use them, but I guess I need to put them in there for other OS?
So, I guess what I want to know is, a user can say they want partition 1 to start on sector X and end on sector Y, so long as they don't overlap with another partition, is there any other special checking I need to do on X and Y to make sure they are acceptable?
Thanks....
Andrew
I mean, that as far as I can tell from what fdisk in linux warns on, that all partitions should either begin at cylinder X, head 0 sector 0, or have a partition table in front of it (due to whatever reason) and start at cylinder Y, head 1, sector 0.Mikae wrote:Do you mean, that every partition must begin with head == 0 value?or that have a partition table there and are aligned at the next head.
Example:
0,0,0: MBR
0,1,0: first partition (primary)
200,0,0: second partition (primary)
420,0,0: extended part. table
420,1,0: third partition (in extended)
500,0,0: fourth partition (in extended)
early versions of MS fdisk would only align on cyl boundaries, later versions used head boundaries as well (but never the first partition), winXP aligns on 8MB (512*64*256 for max sec/cyl, to place the first partition on the first sector of the first head, of the second cyl)
and i would definitely recommend doing as winXP does -- it doesnt take much disk space, and many programs (including boot managers, some older virus scanners, and drive imaging tools) use the space between the MBR and the first partition
for the remaining partitions (other than the first one) i would say it prob wont matter much, as the OS reading the partition will need to use LBA to read it anyway, as the CHS cannot be used on drives larger than 8GB (the CHS fields are only 24bits -- meaning a max of 16.7million sectors, or ~8GB)
btw: does anyone know how the MBR handles 48bit LBA? ...since the LBA fields are only 32bit... i cant seem to find an explaination anyware
and i would definitely recommend doing as winXP does -- it doesnt take much disk space, and many programs (including boot managers, some older virus scanners, and drive imaging tools) use the space between the MBR and the first partition
for the remaining partitions (other than the first one) i would say it prob wont matter much, as the OS reading the partition will need to use LBA to read it anyway, as the CHS cannot be used on drives larger than 8GB (the CHS fields are only 24bits -- meaning a max of 16.7million sectors, or ~8GB)
btw: does anyone know how the MBR handles 48bit LBA? ...since the LBA fields are only 32bit... i cant seem to find an explaination anyware
Hi,
Cheers,
Brendan
You're correct. To support hard disks larger than 2 TiB you need to use a "GUID Partition Table"....Mikae wrote:May be I am totally worng, but I think that for now MBR doesn't handle 48 bit at all...
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
- spix
- Member
- Posts: 128
- Joined: Mon Jun 26, 2006 8:41 am
- Location: Millicent, South Australia
- Contact:
Thanks everyone for your help. I seem to have things working now.
Thanks again
Andrew
I guess this is why the first partition seems to usually start on sector 63?and i would definitely recommend doing as winXP does -- it doesnt take much disk space, and many programs (including boot managers, some older virus scanners, and drive imaging tools) use the space between the MBR and the first partition
Thanks again
Andrew
thanks, thats good to know (somehow, i just knew you would know)Brendan wrote:Hi,
You're correct. To support hard disks larger than 2 TiB you need to use a "GUID Partition Table"....Mikae wrote:May be I am totally worng, but I think that for now MBR doesn't handle 48 bit at all...
Cheers,
Brendan
its good that they used a much longer system type ID number, as there is far too much overlap in the 1 byte IDs in the MBR -- just wish it was for discriptive of the filesystem -- would make a nice, easy to use, way to identify filesystems (the OS can just read the number, and look for a driver supporting that number)
That would be just about anything but winxp, and I'm not sure about winxp.JAAman wrote:uh... check again -- sector 63 LBA is 0:1:1 CHS (32k into the drive)I guess this is why the first partition seems to usually start on sector 63?
winXP uses CHS 1:0:1 (drive translated -- 255 heads) = LBA ~16065 (~8MB into the drive)
though i believe some older MS OSs do use 0:1:1
Ermmm... according to Wikipedia, Windows Data and Linux Data have the same GUID...JAAman wrote:thanks, thats good to know (somehow, i just knew you would know)Brendan wrote:Hi,
You're correct. To support hard disks larger than 2 TiB you need to use a "GUID Partition Table"....Mikae wrote:May be I am totally worng, but I think that for now MBR doesn't handle 48 bit at all...
Cheers,
Brendan
its good that they used a much longer system type ID number, as there is far too much overlap in the 1 byte IDs in the MBR -- just wish it was for discriptive of the filesystem -- would make a nice, easy to use, way to identify filesystems (the OS can just read the number, and look for a driver supporting that number)
http://en.wikipehttp://en.wikipedia.org ... tion_Table
Hi,
It looks like GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 is a generic partition type, which may mean "unknown partition type, look at the legacy BIOS Parameter Block to figure it out"...
There's also an interesting comment on this web page:
Cheers,
Brendan
That might actually be correct (see this Wiki page).TheQuux wrote:Ermmm... according to Wikipedia, Windows Data and Linux Data have the same GUID...
http://en.wikipehttp://en.wikipedia.org ... tion_Table
It looks like GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 is a generic partition type, which may mean "unknown partition type, look at the legacy BIOS Parameter Block to figure it out"...
There's also an interesting comment on this web page:
I think this is talking about the partition type in the BIOS Parameter Block, rather than the GUID...Linux mis-uses the Microsoft Data partition, by creating volumes in it that do not have valid BPBs. This is a fault in Linux. (EXT2/EXT3 partitions could easily be given BPBs. In actual fact, the mke2fs tool has possessed the code for creating valid BPBs since 1996, when it was added by Matthieu Willm. It has simply been conditionally compiled out and relegated to an OS/2 porting section, of all things.).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.