OSDev.org

Is there some tool that allows printing the geometry of a disk like:
or

(Another question would be how to relate drive letters to their buses?)

I need to get the geometry information from the disk hardware itself.
Right now I don't care about the partition geometry, but the one that the ATA commands would return.

Hi,

~ wrote:Right now I don't care about the partition geometry, but the one that the ATA commands would return.

Why?

If it's for performance reasons: For modern hard disks I think there's typically more sectors on outer cylinders (where the circumference/tracks are longer) than there are on inner cylinders (where the circumference/tracks are shorter), so you'd need a different "sectors per track" for each cylinder to make it accurate and geometry returned by ATA commands (which only has a single "sectors per track" value) is mostly just a lie for compatibility purposes. For SSD (e.g. where there aren't any cylinders, etc to begin with) the geometry is an even larger lie. See note.

If it's for setting the CHS values in MBR partitions correctly: In the 1990s disks got too big for the BIOS's CHS scheme, so different BIOSes started using multiple different ways of translating "device CHS" into "fake BIOS CHS" (e.g. pretending there's more heads and less cylinders so "cylinder number" would fit in a 10-bit field, etc). In this case you have to use BIOS services to determine the "BIOS fake geometry" and shouldn't use the raw "ATA fake geometry".

If it's just so you can tell the user what it is: You can just tell the user any kind of nonsense you like - everything else is a lie anyway and it's not like the user has any reason to need accurate information.

Note: It might be at least potentially possible to discover the true geometry from measurements. For example, if you read sectors in order (starting from first sector of first track) and measure how long it takes between the arrival of one sector and the arrival of the next. This "time between adjacent sectors" will either be quick (depending on rotational latency alone) or "medium" (larger rotational latency caused by any gaps at end of old track and start of new track on different head) or slower (depending on seek time). However I doubt it can be that simple. For example, modern hard disks have "spare sectors" that are used to replace faulty sectors, so when you hit a "replaced faulty sector" you'll get higher than expected "time between adjacent sectors" which will break simple/naive measurement (make it look like an "originally adjacent but now relocated" sector is the start of a different head or new cylinder). You'd have to use some sort of heuristical analysis to correct that. Of course this would also take a huge amount of time (reading every sector of the entire disk while nothing else is going on that could upset the timing/measurements); so you'd only want to do it once and store the geometry data somewhere (and maybe build a database or cache so you can use the drive's "vendor and model" to find the geometry quickly).


Cheers,

Brendan

Caching will also hide the actual times to retrieve data from the medium.

Brendan wrote:Hi,

~ wrote:Right now I don't care about the partition geometry, but the one that the ATA commands would return.

Why?

If it's for performance reasons: For modern hard disks I think there's typically more sectors on outer cylinders (where the circumference/tracks are longer) than there are on inner cylinders (where the circumference/tracks are shorter), so you'd need a different "sectors per track" for each cylinder to make it accurate and geometry returned by ATA commands (which only has a single "sectors per track" value) is mostly just a lie for compatibility purposes. For SSD (e.g. where there aren't any cylinders, etc to begin with) the geometry is an even larger lie. See note.

I want to access a second partition with my own functions or another OS. The BIOS allows using the disk with a smaller geometry, but I could handle the rest of the data manually beyond the BIOS and DOS, to use 4 Gigabytes in this 386.

In a 4GB CompactFlash, I pretend to create a boot partition with CHS 1024-16-63 (504 MB).

This is to boot a 386 whose BIOS is optimized to use and detect exactly that geometry (despite being able to use 4-digit values for Disk Type 47).

DOS won't detect more either in this machine, so I need special drivers or another OS after booting to access the rest of the disk (around 3.5 Gigabytes) and create/format that partition, and for that I want to use the CHS values in the card (to surpass regular BIOS and DOS functions and use my own updated routines directly on the hardware).

I guess I could simply create a test snippet to get the IDENTIFY data, in case that such utility doesn't exist.

The best option is to not support broken machines like that.

Hi,

~ wrote:In a 4GB CompactFlash, I pretend to create a boot partition with CHS 1024-16-63 (504 MB).

This is to boot a 386 whose BIOS is optimized to use and detect exactly that geometry (despite being able to use 4-digit values for Disk Type 47).

In that case; you should (in theory) be able to write a "IDE disk controller" driver that supports 16-bit cylinder numbers (giving a maximum limit of up to 31.5 GiB for devices that report 63 sectors per track).

You'd probably also be able to implement it as a "bootable thing" that hooks/replaces "int 0x13" and pretends that the geometry is (e.g.) 1024*256*32 instead; where the "bootable thing" installs itself and then chainloads DOS's boot loader. That way you'd trick DOS into working with the full 4 GiB.

Of course whether or not it's worth bothering with is an entirely different matter.


Cheers,

Brendan