[lkml]   [2004]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.x partition breakage and dual booting
    On Sun, May 30, 2004 at 02:56:30PM -0400, Jeff Garzik wrote:

    > Please educate me :) Brutally, and in public :)

    Hmm. It is easier if you ask questions.
    I already wrote several many-page texts on this stuff.
    See, e.g.,

    Attempt at a brief summary:

    (i) Hardware:

    In the ancient past a disk (MFM or RLL) had a geometry
    describing how many sectors per track, how many tracks (cylinders),
    and how many heads the thing had.

    With the advent of IDE it no longer was true that a disk has a
    well-determined geometry: the ATA command INITIALIZE DRIVE PARAMETERS
    will tell the disk what geometry it is supposed to have today.

    An IDE disk can be accessed in CHS and in LBA mode, and the
    geometry specified, or read via the ATA IDENTIFY command,
    defines the meaning of a CHS command. With LBA access
    no geometry plays a role.

    SCSI disks never had this geometry nonsense.

    Linux uses LBA and does not need to concern itself with geometry.

    (ii) DOS / Windows:

    The DOS disk interface used CHS. If the disk uses LBA the driver
    has to convert CHS to LBA and hence needs a geometry (at least H, S).

    Because DOS (BIOS INT 13) had 10 bits for C, and 6- bits for S,
    while ATA uses 4 bits for H, this scheme could address only
    somewhat less than 2^20 sectors. The 528 MB limit.

    All kinds of translation schemes were invented to give the
    BIOS interface a geometry different from that used at the ATA
    interface. The user chooses a translation scheme in the BIOS setup.
    The geometry is now unrelated to the disk, but is known to the BIOS.

    Various BIOS calls exist that report on various versions of the

    (iii) Partition tables:

    A DOS-type partition table (see, e.g.,
    gives the location of a partition in two ways.
    One is the way used by Linux (the starting sector and length,
    both given in 32 bits). The other, used by DOS, given CHS
    for the first and for the last sector (both in 24 bits).

    Even when nobody cares about geometry any longer, is it still
    necessary to fill these CHS fields.

    If the filesystem living in the partition is a FAT filesystem,
    then the boot sector of the FAT filesystem again gives information
    on the size of the partition.

    (iv) Linux:

    There is an ioctl HDIO_GETGEO that returns the geometry of a disk
    and the starting sector (offset) of a partition.
    There is an ioctl BLKGETSIZE that returns the size (in 512-byte sectors)
    of a block device in 32 bits.
    There is an ioctl BLKGETSIZE64 that returns the size (in bytes)
    of a block device in 64 bits.

    Clearly, BLKGETSIZE is obsolescent - it should be replaced by
    BLKGETSIZE64 everywhere. 2^41 B is 2 TB, and some RAIDs are larger.

    The HDIO_GETGEO ioctl gives heads, sectors and cylinders -
    fields of 1, 1, 2 bytes. On the one hand that is reasonable -
    no interface exists that can use more than 16 bits for the
    number of cylinders. On the other hand there is still some
    broken software that computes the size of a disk as C*H*S,
    and obtains C, H, S by HDIO_GETGEO. Of course this is broken,
    and introducing a new ioctl is no good - such software must
    be fixed to use BLKGETSIZE64.

    (v) Geometry use under Linux:

    Roughly speaking geometry was needed under Linux for two
    purposes: LILO (and similar bootloaders) and *fdisk.
    Of course, also programs that tried to emulate aspects
    of DOS/Windows are interested in a geometry.

    The LILO aspect has disappeared - with options like linear, or lba32,
    lilo uses linear sector numbers at install time, and converts them
    to CHS, when needed, at boot time.

    The fdisk aspect has also disappeared - after this geometry business
    had become infinitely complicated, nobody any longer tried to
    understand geometry, but just inferred from the partition table
    what geometry was used by the program that last wrote it.

    How did the kernel find a geometry?
    Mainly in three ways: (i) from boot parameters, (ii) by looking
    at the partition table, (iii) by asking the BIOS at boot time,
    before switching to protected mode.

    Information (i) - explicit specification - and (ii) - partition table -
    is also available to user space, no kernel needed.
    Remains the question whether (iii) is a good idea.

    It didnt always work, but often it worked. (And only on i386 of course.)
    Examples of failure: The code we had only asked the BIOS for info
    on the first two disks. An often-posed question was: I have two
    identical disks, how come they get different geometries?
    Also, the code we had failed when the system had SCSI disks.
    Also, the code we had assumed that the first two BIOS disks
    were hda and hdb. But there is no reason why that would be
    the case. For example, many people kept their large disks out of the
    BIOS since it would crash upon seeing big disks.

    So, this (iii) was a bit messy stuff with many problems, but
    OK for most people.

    (vi) The present

    Linux no longer makes any attempt to invent a geometry.
    If someone needs a geometry, he is responsible himself
    for choosing one of the many concepts of geometry, and
    determining a value. What most software does is looking
    at the partition table, and that works.

    Maybe parted has not yet been updated to do this,
    that is why I conjectured that Fedora problems might be
    due to the use of parted.

    Was this a loss? I don't think so, but there is at least
    one use of the old situation that fails today:
    the installation of Windows systems from Linux media
    on a completely blank disk.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.026 / U:24.644 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site