Categories

I was trying to figure out how to get the raw size of a blank disk (no MBR). For the Windows readers, I am talking about disks that have not been “signatured” yet.

Intuitively, you only need to get the c/h/s or lba values and some 5th grade Math knowledge. This is how generally tools like parted work.

The tricky part is to get these values.

If you try to read the geometry values from the MBR, as parted does, it won’t work with a blank disk. cfdisk and grub also read the geometry from the partition table but fall back to ioctl()’s HDIO_GETGEO if they couldn’t read the head/sectors from the MBR. Have a look at the following patch:

http://svn.debian.org/wsvn/pkg-grub/grub/trunk/debian/patches/geometry-26kernel.diff?op=file&rev=0&sc=0http://svn.debian.org/wsvn/pkg-grub/grub/trunk/debian/patches/geometry-26kernel.diff?op=file&rev=0&sc=0

But, as described by hdio.txt, the values returned by ioctl() are not meaningful for modern drives:

Not particularly useful with modern disk drives, whose geometry is a polite fiction anyway.  Modern drives are addressed purely by sector number nowadays (lba addressing), and the
drive geometry is an abstraction which is actually subject to change.  Currently (as of Nov 2004), the geometry values are the "bios" values -- presumably the values the drive had when Linux first booted.

In addition, the cylinders field of the hd_geometry is an unsigned short, meaning that on most architectures, this ioctl will not return a meaningful value on drives with more than 65535 tracks.

The start field is unsigned long, meaning that it will not contain a meaningful value for disks over 219 Gb in size.

(a thread on the linux-kernel ml on the topic: http://www.uwsg.iu.edu/hypermail/linux/kernel/0602.1/0898.html)

The so called “bios” values are the one returned by INT13 (see arch/i386/boot/edd.S in the kernel source):

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/i386/boot/edd.S;h=4b84ea216f2b81ede738e80206a5fafd8e5ef994;hb=2c3ca07d2f691a463b715c83122c87f57c2a7b7c

So basically, the safe way to go is only to rely on the number of blocks (for modern drives and bios supporting lba, this should be the ‘real’ value; for c/h/s, you need to trust your bios) and assume 512 bytes for the block size. Note that the sysfs knows the number of blocks ( see /sys/block/*/size).

I’m still wondering how you can check for the block size. Is 512 considered as an industry standard?