Re: a few words on BIOS/FDISK geometry

From: Jerry McAllister (jerrymc_at_clunix.cl.msu.edu)
Date: 01/26/04

  • Next message: Eric F Crist: "Re: Spam Assassin?" 
    To: strick@covad.net (Dan Strick)
Date: Mon, 26 Jan 2004 10:42:24 -0500 (EST)

    Wow,

    Have you put this up as a FAQ somewhere? It seems like a good idea
    to do so.

    ////jerry

    > I find most of the BIOS/MBR/FDISK disk geometry gospel that has recently
    > appeared in freebsd-questions to be confusing if not actually incorrect.
    > In the interest of world peace of mind, I feel compelled to offer my own
    > model of reality. It really isn't that complicated.
    >
    > There are two common ways in which disk sector addresses are expressed.
    > These are the LBA (Logical Block Address) number and the C/H/S (Cylinder/
    > Head/Sector) numbers. As pretty much everyone knows, the LBA and C/H/S
    > values are related by an expression similar to:
    >
    > LBA = (C*NH + H)*NS + S
    >
    > where NH is the number of heads and NS is the number of sectors/track.
    > C/H/S used to be the most common address representation but LBA has since
    > gained popularity because it is conceptually simpler (is only one number)
    > and because C/H/S numbers are typically limited to inconveniently small
    > values. The physical significance of the NH and NS values has been
    > largely eroded by the advancement of technology. We now only use these
    > values when converting between sector address representations.
    >
    > The system BIOS provides a basic disk access facility sometimes called
    > "int13". There are different int13 "functions" for things like reading,
    > writing and obtaining disk parameters such as geometry. The original
    > "basic" int13 functions, implemented by essentially all versions of PC
    > BIOS, expect sector addresses to be in C/H/S format. There is also a set
    > of "extended" int13 functions, implemented by newer BIOS, that expect
    > sector addresses to be in 64 bit LBA format.
    >
    > The disk geometry assumed by the basic int13 functions is what we mean
    > by the term "BIOS geometry". The BIOS may describe different geometries
    > for a single disk drive in different contexts. We only care about the
    > geometry the BIOS uses to interpret the disk addresses used with the
    > basic int13 functions. Note that the BIOS geometry may not be related
    > to any physical or logical geometry used by the disk itself.
    >
    > The common FreeBSD master bootstrap program may be installed and
    > configured with the "boot0cfg" command. It uses the basic int13
    > functions by default but may be configured to use the extended functions
    > (the "packet" option). When a FreeBSD partition is booted, the boot0
    > program boots the boot1 program in the second sector of the partition.
    > The boot1 program in turn boots the boot2 program. I don't know if
    > these programs use basic or extended int13 functions or at what point
    > in the bootstrap sequence the bootstrap programs stop using the BIOS.
    >
    > The MBR (Master Bootstrap Record) partition table (aka FreeBSD slice
    > table) which is stored in the first sector of most PC disk drives
    > contains the starting address of each partition in both C/H/S and LBA
    > format. There are 10 bits in the cylinder field, 8 bits in the head
    > field, 6 bits in the sector field and 32 bits for the LBA field.
    > By (MS?) convention cylinder and head numbers begin at 0 but the first
    > sector number is 1. There is allegedly some important program (unknown
    > to me) which limits the number of heads to 255. Programs that use the
    > basic BIOS int13 functions to access partitions defined in an MBR can
    > address at most 1024 cylinders, 255 heads and 63 sectors (somewhat less
    > than 8 GB).
    >
    > (An explanation of the many disk sizes to which PC systems are sometimes
    > limited is tempting but way beyond the scope of this posting.)
    >
    > The FreeBSD fdisk program needs to know the disk geometry only when
    > filling in the C/H/S fields in the MBR partition table. If it gets the
    > geometry wrong, bootstrap programs that use the basic int13 functions
    > may fail. (Programs that use the extended int13 functions will not
    > be affected!)
    >
    > The FreeBSD fdisk program sometimes gets the BIOS geometry wrong and we
    > have to correct it. How can we determine the correct BIOS geometry of a
    > disk drive in this case? BIOS configuration user interfaces can be
    > confusing and the disk drive geometries they report may not always be
    > those used by the basic int13 functions. The only (usually) reliable way
    > to get a BIOS disk geometry may be to ask the BIOS via one of the int13
    > functions or to read it out of one of the data structures left behind by
    > the BIOS POST (power on self test).
    >
    > Sometimes if we boot a FreeBSD kernel with the "-v" option it will tell
    > us the BIOS geometries during the autoconfiguration monologue. I am not
    > sure that I trust it. Sometimes software will report disk controller
    > interface geometry instead. (Hint: if a geometry specifies more than
    > 255 heads or 63 sectors/track, you know it is not the BIOS geometry.)
    > I sometimes boot grub (see /usr/ports/sysutils/grub) off a floppy and ask
    > it about a disk drive with the "geometry" command. As far as I know,
    > this will reliably report the BIOS geometry.
    >
    > Modern BIOS geometry most frequently uses 255 heads and 63 sectors/track
    > because that maximizes the addressable part of the disk drive using the
    > basic int13 functions. Cylinder numbers greater than 1023 don't really
    > matter because whatever you put in the MBR will be wrong. I typically
    > manually set them to 1023. Remember that you can only boot partitions
    > beyond cylinder 1023 if all bootstrap programs use the extended int13
    > functions.
    >
    > Dan Strick
    > strick@covad.net
    > _______________________________________________
    > freebsd-questions@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
    >

    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"

  • Next message: Eric F Crist: "Re: Spam Assassin?"

    Relevant Pages

    • Re: Support HDIO_GETGEO on device-mapper volumes
      ... most of the time these days the bogus values do match the bios values. ... If grub is using HDIO_GETGEO then yea, it should just use the geometry in the MBR instead. ... It should assume that the values stored in the MBR already are correct, since if they weren't, the system wouldn't boot anyhow, and use those rather than ask the kernel. ... disk in a compatible way. ...
      (Linux-Kernel)
    • Re: a few words on BIOS/FDISK geometry
      ... >> There are two common ways in which disk sector addresses are expressed. ... >> The system BIOS provides a basic disk access facility sometimes called ... >> writing and obtaining disk parameters such as geometry. ... >> The disk geometry assumed by the basic int13 functions is what we mean ...
      (freebsd-questions)
    • RE: Drive Geometry -- confusion.
      ... > Drive Geometry confusion. ... > The following are the only settings offered by my BIOS: ... limitations of "BIOS" disk addressing, ... down the DEL key) may tell you about some ATA/IDE drives, ...
      (freebsd-questions)
    • a few words on BIOS/FDISK geometry
      ... I find most of the BIOS/MBR/FDISK disk geometry gospel that has recently ... There are two common ways in which disk sector addresses are expressed. ... "basic" int13 functions, implemented by essentially all versions of PC ... BIOS, expect sector addresses to be in C/H/S format. ...
      (freebsd-questions)
    • Re: Grub hangs - two hard drives and a CD
      ... > What you wrote is all based on a wrong assumption that grub numbers drives ... > that the BIOS will call to boot an OS. ... The Bios calls to read disk require the register DL to ...
      (comp.os.linux.setup)