[9fans] fdisk: reported number/size of cylinders changes

[9fans] fdisk: reported number/size of cylinders changes

[Axel Belinfante]

Something funny I noticed when using
fdisk on a new 80Gb Maxtor hard disk
(diamondmax plus 9).

When I used fdisk on the new disk,
it reported
	9809 cylinders of 8355840 bytes.

After making and saving a partition, quitting
and restarting fdisk reports
	39704 cylinders of 2064384 bytes.

(type script included at the end)

After zeroing (the start of) the disk,
fdisk again reports the 9809 * 8355840.

This surprised me.

In case it matters, I'm doing this on an old
Gigabyte motherboard (GA-686SGM), which had
a bios that did not support big disks, which
I flashed with a bios someone (unfortunately,
not gigabyte) patched for big disks.
Is this BIOS playing tricks on me?
(How much) should this worry me?

I did not (yet) repeat the experiment on a
different motherboard. (planning to do that,
but thought I'd mention it here first anyway)
It looks like I'm doing this with an older
kernel (Feb 18) but fdisk is recent.

Something else I noticed:
for this disk (80Gb maxtor diamondmax plus 9)
the ctl capabilities line does not contain dma
or dmactl; for the 80Gb maxtor diamondmax plus d740X
dma/dmactl are present in the ctl capabilities.

Confused,
Axel.



Just to be complete:

term% disk/fdisk /dev/sdD0/data
disk/fdisk: did not find master boot record
term% disk/mbr -m /386/mbr /dev/sdD0/data
term%  disk/fdisk /dev/sdD0/data
cylinder = 8355840 bytes
   empty                  0 9809        (9809 cylinders, 76.33 GB)
>>> a p1
start cylinder: 0
end [0..9809] 130
>>> t p1
new partition type [? for list]: FAT32
>>> p
'  p1                     0 130         (130 cylinders, 1.01 GB) FAT32
   empty                130 9809        (9679 cylinders, 75.32 GB)
>>> w
>>> q
term% disk/fdisk /dev/sdD0/data
cylinder = 2064384 bytes
   p1                     0 526         (526 cylinders, 1.01 GB) FAT32
   empty                526 39704       (39178 cylinders, 75.32 GB)
>>>

Re: [9fans] fdisk: reported number/size of cylinders changes

[David Presotto]

It is true that most IDE's are chameleons, i.e., they can be told to
display their geometry in different ways, i.e., with different numbers
of cylinders, heads, and sectors.  The identify command tells us the
geometry.  There is both a 'logical' and a 'actual' set of values in
what is returned.  We use the actual if its valid (a certain bit is
set) but it may very well not be.  Did you happen to get to plan 9
differently in the two instances?  It could be that you're just seeing
two different logical geometries of the same disk.  In LBA mode, we
don't use the logical geometries except to determine the number of
disk blocks, so you should be OK in both cases (modulo the fact that
one comes out to less sectors).

Re: [9fans] fdisk: reported number/size of cylinders changes

[Axel Belinfante]

I booted plan 9 in the same way in both cases
(kernel from flop, fs over the net).

In /sys/src/libdisk/disk.c I found the following comment
near the opendisk code, which explains the difference between
opening a ``clean'' empty disk, and one already containing
a partition table. However, I would have expected that
reading (and using) the partition table on disk would
give me back the number previously shown (and, written,
I assume), by fdisk when I ran it first time.

Axel.

Comment found in /sys/src/libdisk/disk.c:

 * Discover the disk geometry by various sleazeful means.
 *
 * First, if there is a partition table in sector 0,
 * see if all the partitions have the same end head
 * and sector; if so, we'll assume that that's the
 * right count.
 *
 * If that fails, we'll try looking at the geometry that the ATA
 * driver supplied, if any, and translate that as a
 * BIOS might.
 *
 * If that too fails, which should only happen on a SCSI
 * disk with no currently defined partitions, we'll try
 * various common (h, s) pairs used by BIOSes when faking
 * the geometries.

[maybe I should check that for the clean disk the
 second case is used, and not the third]

> Did you happen to get to plan 9 differently in the two instances?
> It could be that you're just seeing two different logical geometries
> of the same disk.  In LBA mode, we don't use the logical geometries
> except to determine the number of disk blocks, so you should be OK
> in both cases (modulo the fact that one comes out to less sectors).

Re: [9fans] fdisk: reported number/size of cylinders changes

[David Presotto]

I'ld dump a bunch of prints in fdisk and see what it thinks its
doing.  At 835840 bytes/cylinder, the cylinders don't come out
a multiple of 512 bytes which seems rather odd.

Re: [9fans] fdisk: reported number/size of cylinders changes

[Axel Belinfante]

When I looked at the fdisk source, I got the impression that
it takes the disk geometry info from opendisk, so maybe also
there interesting things happen (see the comment I posted in prev msg)

I'll find some time (sometime next couple of days) and experiment a bit;
when I find/know more, I'll post here.

Thanks for listening!
Axel.


> I'ld dump a bunch of prints in fdisk and see what it thinks its
> doing.  At 835840 bytes/cylinder, the cylinders don't come out
> a multiple of 512 bytes which seems rather odd.

Re: [9fans] fdisk: reported number/size of cylinders changes

[Russ Cox, rsc]

Libdisk/disk.c is where you want to look.
Fdisk doesn't know anything about guessing
geometries.