OSDev.org

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

Strictly speaking, they can be anything.

Most OSes only accept those that are either aligned on a cylinder boundary, or that have a partition table there and are aligned at the next head.

or that have a partition table there and are aligned at the next head.

Do you mean, that every partition must begin with head == 0 value?

Mikae wrote:

or that have a partition table there and are aligned at the next head.

Do you mean, that every partition must begin with head == 0 value?

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.

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

JAAman wrote: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

If it looks like a duck, quacks like a duck and waggles like a duck, it most likely is a duck.

btw: does anyone know how the MBR handles 48bit LBA?

May be I am totally worng, but I think that for now MBR doesn't handle 48 bit at all...

Hi,

Mikae wrote:May be I am totally worng, but I think that for now MBR doesn't handle 48 bit at all...

You're correct. To support hard disks larger than 2 TiB you need to use a "GUID Partition Table"....


Cheers,

Brendan

Thanks everyone for your help. I seem to have things working now.

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

I guess this is why the first partition seems to usually start on sector 63?

Thanks again
Andrew

I guess this is why the first partition seems to usually start on sector 63?

uh... check again -- sector 63 LBA is 0:1:1 CHS (32k into the drive)

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

Brendan wrote:Hi,

Mikae wrote:May be I am totally worng, but I think that for now MBR doesn't handle 48 bit at all...

You're correct. To support hard disks larger than 2 TiB you need to use a "GUID Partition Table"....


Cheers,

Brendan

thanks, thats good to know (somehow, i just knew you would know)

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)

JAAman wrote:

I guess this is why the first partition seems to usually start on sector 63?

uh... check again -- sector 63 LBA is 0:1:1 CHS (32k into the drive)

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

That would be just about anything but winxp, and I'm not sure about winxp.

JAAman wrote:

Brendan wrote:Hi,

Mikae wrote:May be I am totally worng, but I think that for now MBR doesn't handle 48 bit at all...

You're correct. To support hard disks larger than 2 TiB you need to use a "GUID Partition Table"....


Cheers,

Brendan

thanks, thats good to know (somehow, i just knew you would know)

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)

Ermmm... according to Wikipedia, Windows Data and Linux Data have the same GUID...
http://en.wikipehttp://en.wikipedia.org ... tion_Table

Hi,

TheQuux wrote:Ermmm... according to Wikipedia, Windows Data and Linux Data have the same GUID...
http://en.wikipehttp://en.wikipedia.org ... tion_Table

That might actually be correct (see this Wiki page).

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:

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.).

I think this is talking about the partition type in the BIOS Parameter Block, rather than the GUID...


Cheers,

Brendan