lkml.org 
[lkml]   [1999]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: over 5Gb missing from a 13.5Gb disk
On Tue, Dec 07, 1999 at 01:57:03PM -0700, TimO wrote:
> Guest section DW wrote:

> > You cheat yourself by using a hdparm/kernel combination that lies
> > to you. Try hdparm -I to see the truth.
> >
> > (Yes, in the good old days "hdparm -i" was useful. These days it gives
> > corrupted info, and one needs "hdparm -I".)
>
> Interesting... I take it then that -i just reads the information from the
> drive firmware itself and -I gives what the kernel is actually using!?

No - "hdparm -I" tells you what the drive answers to an IDENTIFY command
right now. It does actual I/O to the drive. In the good old days "hdparm -i"
would tell you what the drive answered to the IDENTIFY command at boot time.
Today it is just worthless - the meaning of the output depends strongly on
kernel version, and many kernel versions scribble in this identify output
so that it is a strange combination of disk data and kernel data.

The present kernel data is found using "hdparm -g" or "sfdisk -g" or so.
The kernel bootup info ("dmesg | grep hd") tells what happened at boot time.
And "hdparm -I" tells us what the disk says. Usually this information
(together with the kernel version) suffices to solve all problems.

> Note that -i returns exactly the manufacturer's specs as written on the
> drive, even the suggested LBA c/h/s.

I can hardly imagine that the manufacturer suggests CHS=930/512/63.
Indeed, H cannot be larger than 255.

> Why is it that -I returns the vendor
> information in BE byte pairs?

That is what the disk returns.

> spazz:~# hdparm -I /dev/hda
>
> /dev/hda:
>
> Model=aMtxro9 51636U , FwRev=AV15R00F,
> SerialNo=6W90SNA8
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
> CurCHS=65535/1/63, CurSects=4128705, LBA=yes
> LBA CHS=1023/64/63 Remapping, LBA=yes, LBAsects=30000096
>
> spazz:~# hdparm -i /dev/hda
>
> /dev/hda:
>
> Model=Maxtor 91536U6, FwRev=VA510RF0, SerialNo=W609NS8A
> RawCHS=29762/16/63, TrkSize=0, SectSize=0, ECCbytes=57
> CurCHS=29762/16/63, CurSects=30000096, LBA=yes
> LBA CHS=930/512/63 Remapping, LBA=yes, LBAsects=30000096

Funny - this is really broken output.
RawCHS=16383/16/63 is as it should be, and so is LBAsects=30000096.

But the "CurCHS=65535/1/63, CurSects=4128705" is surprising.

The "LBA CHS=1023/64/63 Remapping" and "LBA CHS=930/512/63 Remapping"
are just hdparm bugs. Must be hdparm 3.5 or so - this is pure fantasy.

So, I was too optimistic when I said that "-I" gave data straight
from the disk - it contains strange nonsense as well.
Shame over the hdparm maintainer, Mark or Andre or whoever put this in.
Once more: "hdparm -i" must give the disk identify answers at boot time.
And "hdparm -I" must give the disk identify answers now.
And the kernel must not change this into what it thinks the disk should have said.
And hdparm must not invent geometries not used by the disk and not
used by the kernel, confusing even more people. This "LBA CHS" junk must go.


Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.098 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site