Messages in this thread | | | Date | Tue, 7 Dec 1999 23:45:24 +0100 | From | Guest section DW <> | Subject | Re: 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/
| |