Re: Disk mapping confusion with the device command

[Phillip Susi]

Molle Bestefich wrote:

That's not correct.  BIOSs use a variety of LBA<->CHS algorithms, and
using the wrong one will cause Grub to load the wrong sectors upon
reboot, obviously.

My Compaq here fx. uses an algorithm called Bit Shifting, which with
my current disk results in 240 heads, not 255.  I've seen documented
somewhere that other BIOSs adjust their decision on the number of
heads depending on the exact size of the disk.   The motivation for
doing this is that it will give you a few extra MBs when the actual
LBA<->CHS math is done, due to rounding.
  

Hrm... interesting.... I wonder where fdisk got it's numbers then?  And where did grub get it's numbers, and why were they different than fdisk? 

[side note]
For some reason, I've never seen a BIOS adjust the sectors/track
number.  I haven't done the math, but one could suspect that there's
no gain in adjusting the s/t number, at least when already adjusting
the head numbers?  Could probably be easily determined - find out how
many divisions are involved in the calculation, for each division
there's a rounding error which can be minimized if you fiddle with the
numbers.  (One would have to trust that all BIOS manufacturers
actually chose the equation with the least number of divisions.....)
[/side note]

  

There is no rounding error.  This is all integer math.  The one reason I can think of for minimizing the number of heads is because by default, fdisk aligns partitions on cylinder bounderies, which wastes more space the larger a cylinder is.  This behavior is antiquated and unneccesary, which is why I allways change fdisk to sector mode and use every last sector. 

The discussion is a bit moot when it comes to actually booting new
systems, however.  They all support LBA extensions to int13 anyway. 
The only thing that matters with new systems is to make sure that the
CHS numbers in MBR cause the partitions to _land on cylinder
boundaries_ - otherwise neither DOS nor Win9x/ME will boot.  I suspect
that Win2000/XP/2003 will not either, though it will take some testing
before I'm 100% sure.
[side note] Not a particular hard feature to implement, but for some
reason neither FDISK nor Partition Magic can do this.  Guess neither
tool expects that people move disks from one BIOS to another or fiddle
with BIOS settings or 'dd' from a smaller drive to a larger one.
[/side note]

  

I believe dos WILL boot from partitions not cylinder aligned, it just creates them cylinder aligned by default.  I believe that NT/2K/XP aligns the end of partitions to cylinder bounderies, which is why there is usually up to 8 megs of free space at the end of the disk.  The start of the partition though, it seems to only align to the nearest head.  If you create a single partition for the whole disk, you end up with a partition that starts on sector 63, and ends on the last whole cylinder, leaving any partial cylinder beyond that unused. 

I've never understood why the Grub command line interface should care
about CHS numbers.  As far as I can see, that's an implementation
detail which can safely be forgotten about until the system is
actually about to boot.  At that time, if the BIOS that the disk is
plugged into at the time does not support int13 LBA extensions, it's a
simple matter of asking the BIOS for disk geometry (also through
int13) and converting the LBA numbers embedded in the Grub boot sector
to CHS numbers, then loading the correct sectors.
  

Good point. 

Oh, wait.  I can conceive one possible use for knowing the CHS
numbers:  Making sure that none of the sectors that your kernel file
occupies lies at the very end of the disk, on one of the sectors that
is "discarded by the BIOS" due to rounding error.  In case the BIOS
only supports CHS, that would leave one with a non-bootable system.  I
suspect that currently, Grub just ignores this factor and relies on
being lucky - there's a quite good chance that the kernel file won't
land on one of those sectors.
  

Again, there is no rounding error, it's simply that CHS mode does not have enough bits to specify addresses higher than 8 GB.  Also, grub does not check the kernel file or menu.lst locations when you install it, it reads those at boot time.  The only file that grub needs to map the absolute sector locations for is the stage 1.5/2 loader.  It might check to make sure that file is accessible to the bios, I don't know. 

I think the easier solution to this problem is to do the math in FDISK
- just don't allow partitions that occupy the space at the very far
end of the disk.  As far as I can see, at most 1 fake-cylinder can be
lost, so excluding 1*255*63 sectors = 7.8 MBs should do.  Seems it's
both easier to do it at FDISK time, and also you actually *do*
something about the problem, instead of just being able to tell the
user that it won't be bootable unless (s)he moves the boot files.
  

What benefit does not using the last 7.8 MB of the disk provide?  Or maybe I'm not understanding you. 

The above is also a Good Thing for another reason, which is that
Windows/Veritas systems might leave special metadata at end-of-disk,
outside a partition.
  

IIRC, they write a partition table that shows most of the disk used by a big partition, and inside that partition, there are user created partitions with some reserved space at the end for the LVM metadata. 

(FDISK should probably have a --force option to manually include the
last sectors, for the freaks out there that run Linux-only on a
LBA-int13-enabled system and are pissed about loosing 7 MB :-))...

  

Just throw it in sector mode with the u command and it will use every availible sector instead of aligning to cylinders. 

As I said above, aligning the start of a partition to a cylinder
boundary thus allowing various braindead operating systems to work is
an easy feat.  (I'm assuming that no known filesystem uses absolute
disk sector numbers, only start-of-partition-relative numbers.  If
anyone thinks I'm wrong, speak up.)
  

FAT and NTFS boot sectors contain a field called 'hidden sectors' which is the absolute sector number of the boot sector.  That number is added to the IO that the boot sector does to load the rest of the system. 

PartitionMagic can't do this feat - it will bark an error message at
you and quit.  But it does have another interesting feature.  If the
start of the partition is aligned correctly, but the end isn't (I
think!), it adjusts the Head number in the end CHS coordinates.  It
leaves Cylinder and Sector maxed out, but fiddles with the Head
number.  I'm imagining that perhaps the PowerQuest folks did thorough
analyses and found that some other tool or operating system code
messes up your disk if you just max out both numbers, but I can't be
entirely sure.  If someone can shed some light on this, I'd be very
interested in knowing what the motivation is :-).  Also it might very
well be something that's worth fixing in Linux FDISK.
  

I don't trust partition magic any further than I can throw it.  Of the 4 times that I have used or seen someone use it, 3 times it completely trashed the contents of the disk.  Because of this, I choose to assume that anything they do is either wrong or by accident, not something well thought out with good reasoning that I simply don't know about.