LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/LDP/LG/issue37/tag/31.html

1403 lines
52 KiB
HTML
Raw Permalink Blame History

<!--startcut ======================================================= -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<META NAME="generator" CONTENT="lgazmail v1.1H.i">
<TITLE>The Answer Guy 37: Ultra-DMA and the 8.4Gb IDE Disk Limit</TITLE>
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
LINK="#3366FF" VLINK="#A000A0">
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<H4>"The Linux Gazette...<I>making Linux just a little more fun!</I>"</H4>
<P> <hr> <P>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<center>
<H1><A NAME="answer">
<img src="../../gx/dennis/qbubble.gif" alt="(?)"
border="0" align="middle">
<font color="#B03060">The Answer Guy</font>
<img src="../../gx/dennis/bbubble.gif" alt="(!)"
border="0" align="middle">
</A></H1>
<BR>
<H4>By James T. Dennis,
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
Starshine Technical Services,
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A>
</H4>
</center>
<p><hr><p>
<!-- endcut ======================================================= -->
<!-- begin 31 -->
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
height="50" width="60" alt="(?) " border="0"
>Ultra-DMA and the 8.4Gb IDE Disk Limit</H3>
<p><strong>From R. Brock Lynn on Sun, 17 Jan 1999
</strong></p>
<!-- ::
Ultra-DMA and the 8.4Gb IDE Disk Limit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:: -->
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Hi Jim,
</STRONG></P>
<P><STRONG>
We met briefly at USENIX '98. I sat in front of you in the <A HREF="http://www.redhat.com/">Red Hat</A>
Admin Tutorial.
<IMG SRC="../../gx/dennis/smily.gif" ALT=":)"
height="24" width="20" align="middle"> I think you had asked me about bochs or
something like that. But I haven't done anything with it for a
while... limited drive space until just this xmas when I bought
two brand new 10 gig IDE (ATA3) IBM Deskstar drives.
</STRONG></P>
<P><STRONG>
And I can't for the life of me get the full 10 gigs on each to be
recognized! I get only a flat 8gig each!
</STRONG></P>
<P><STRONG>
I'm running <A HREF="http://www.debian.org/">Debian</A> 2.0 Hamm, with Kernel 2.2.0-pre6 with a PPRO
single processor board, made in 1995, with the latest BIOS upgrade
my vendor has available, circa. Feb., 1997. (bought the thing in
'97) Cybermax: www.cybmax.com was the vendor.
</STRONG></P>
<P><STRONG>
Anyhow, the darned IBM drives only show up under Linux as 8gig. To
be precise here is output of "df": (I included the full output
just in case the added data might be useful. Yep, I've got as many
drives as IDE can handle)
</STRONG></P>
<PRE><STRONG>
# df
Filesystem 1024-blocks Used Available Capacity Mounted on
<TT>/dev/hda5</TT> 967677 880562 77116 92% /
<TT>/dev/hda1</TT> 1028116 1017468 10648 99% <TT>/mnt/c</TT>
<TT>/dev/hdb1</TT> 8609416 64304 8545112 1% <TT>/mnt/bigboy1</TT>
<TT>/dev/hdd1</TT> 8615982 64304 8551678 1% <TT>/mnt/bigboy2</TT>
<TT>/dev/sda4</TT> 98078 97394 684 99% <TT>/mnt/zip</TT>
<TT>/dev/hdc</TT> 108240 108240 0 100% <TT>/mnt/cdrom</TT>
</STRONG></PRE>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Not quite! You could have <TT>/dev/hdd</TT> --- for a total of
four IDE drives on two channels. I've heard of people
running more than that --- but I think that's just silly.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
And according to "bc"
8545112 bytes <TT>/</TT> 1024 bytes per meg <TT>/</TT> 1024 megs per gig = 8 gigs
</STRONG></P>
<P><STRONG>
The c/h/s numbers printed on both drives:
chs: 16383/16/63
lba: 19,807,200
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Hmm. Those don't add up. But I'm not surprised.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I wish I knew how to calculate total space in megs using C/H/S numbers!
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Sectors are 512 bytes. You multiple cylinders (C), heads
(H), and sectors per track (S) to get the total number of
sectors. Think of track as one head on one cylinder. That
is to say that it is one concentric ring on one side of
one platter.
</BLOCKQUOTE>
<BLOCKQUOTE>
That's all really a fiction since all of the high capacity
drives in the last decade (everything over about 200Mb)
have used "ZBR" (zone bit recording) and consequently don't
physically have the same number of sectors per track out
the outer "zones" (rings) of the platters as they do on
the inner zones.
</BLOCKQUOTE>
<BLOCKQUOTE>
The drive electronics hide these details from the rest
of the hardware so that the BIOS can "pretend" that it
really is an even number of sectors on a given number of
heads with a given number of tracks. The drives (SCSI and
IDE) will "auto translate" into BIOS compatible disk
addresses (CHS). (Actually SCSI controllers usually
replace the BIOS routines that handle this --- but
effectively the drive is still abstracting most of the
details away from the controller and the OS).
</BLOCKQUOTE>
<BLOCKQUOTE>
The BIOS was only set to handle 10 bits of cylinder (1024
maximum), six bits of sector (per track) and eight bits
of "head" which fits neatly into a 16 bit register and
one byte register. Those were convenient for programming
the 8086 based systems that were common about 20 years ago.
</BLOCKQUOTE>
<BLOCKQUOTE>
(They're pretty silly now).
</BLOCKQUOTE>
<BLOCKQUOTE>
In any event the famed 8Gb limit is derived from
</BLOCKQUOTE>
<blockquote><pre>max cylinders * max sectors * max heads
= maximum total sectors
</pre></blockquote>
<BLOCKQUOTE>
or:
</BLOCKQUOTE>
<blockquote><pre>1024 * 64 * 255 = 16777216
</pre></blockquote>
<BLOCKQUOTE>
which we convert to Kilobytes, Megabytes and Gigabytes
by:
</BLOCKQUOTE>
<blockquote><pre>16777216 / 2 = 8388608 (maximum total K)
/ 1000 = 8388 (maximum total Mb)
/ 1000 = 8.4 (maximum total Gb)
</pre></blockquote>
<BLOCKQUOTE>
... note that we don't use 1024 to compute Mb and Gb.
This is common practice among drive manufacturers (and
unheard of for memory chips). That has been a matter of
some controversy as those extra 24 K per Mb start to had up
when you're doing them by the thousand.
</BLOCKQUOTE>
<BLOCKQUOTE>
I won't pretend to be authoritative on that subject.
Let's suffice to say that given the original contraints
of the BIOS addressing system the maximum addressable space
(in 512 byte sectors) is between 8 and 8.4 Gb (depending
on how you calculate your Gigabytes).
</BLOCKQUOTE>
<BLOCKQUOTE>
Over the years there have been various other limitation
with parts of that. This trick of lying about the number
of "heads" and claiming that there were 255 heads was
the earliest way to over come the "1024 cylinder problem"
--- which had lead to the early "540Mb" limit on IDE
drives. Various different ways of accomplishing this were
labelled EIDE and ATA-2. We no have ATA-3 and UltraDMA.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
fdisk reports these numbers for each of the disks:
</STRONG></P>
<Pre><STRONG>
/dev/hdb:
=====================================================================
Disk /dev/hdb: 255 heads, 63 sectors, 1232 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Begin Start End Blocks Id System
/dev/hdb1 1 1 1232 9896008+ 83 Linux native
=====================================================================
/dev/hdd:
=====================================================================
Disk /dev/hdd: 16 heads, 63 sectors, 19650 cylinders
Units = cylinders of 1008 * 512 bytes
Device Boot Begin Start End Blocks Id System
/dev/hdd1 1 1 19650 9903568+ 83 Linux native
=====================================================================
</STRONG></Pre>
<P><STRONG>
Strange I know that different numbers of cylinders and heads are
reported for the two drives since they are identical models: IBM
#DTTA-351010
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
The drive's electronics will take all of the parts of any
address (CHS) that are presented to it and multiply them
all together to get a "linear block address" (LBA). So
It really doesn't matter what your CMOS says.
</BLOCKQUOTE>
<BLOCKQUOTE>
However, you probably have to add lilo.conf directives
to pass the drive's true "geometry" to the kernel
(so it will ignore the CMOS values).
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Here is my <TT>/etc/lilo.conf</TT> in case it might help:
</STRONG></P>
<Pre><STRONG>
=========================================================================
boot = /dev/hda # Device containing boot sector
default = 2.2.0-pre6 # Default image to load
prompt # Forces boot prompt
timeout = 50 # Wait &lt;val&gt;/10 sec. after prompt then boot def
image = /boot/vmlinuz-2.0.33
label = 2.0.33
root = /dev/hda5
read-only
vga = 8
append = "mem=143M"
image = /boot/vmlinuz-2.0.36
label = 2.0.36
root = /dev/hda5
read-only
vga = 8
append = "mem=143M"
image = /boot/vmlinuz-2.2.0
label = 2.2.0-pre6
root = /dev/hda5
read-only
vga = 8
other = /dev/hda1
label = win95
table = /dev/hda
==========================================================================
</STRONG></Pre>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
First try adding the "<tt>linear</tt>" directive to your lilo.conf
"Global" section.
</BLOCKQUOTE>
<BLOCKQUOTE>
See if that helps.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I have each drive in LBA mode in the BIOS with the autodetected
settings. CHS autodetected match the numbers printed on the
drive, but the BIOS only sees 8 gig I believe.
</STRONG></P>
<P><STRONG>
I just don't know what the deal is.
</STRONG></P>
<P><STRONG>
There is some rucus on "Ask Slashdot" about this same thing, how
to overcome the 8gig barrier with Linux: but I'm at a loss for
trying so many things.
</STRONG></P>
<P><STRONG>
<A HREF="http://slashdot.org/askslashdot/98/12/22/1143236.shtml"
>http://slashdot.org/askslashdot/98/12/22/1143236.shtml</A>
</STRONG></P>
<P><STRONG>
Perhaps you can help investigate this further, and finally put
this problem to rest once and for all in the annals of Linux
Gazette!
</STRONG></P>
<P><STRONG>
If there is any other info you may need about my system, please
don't hesitate to ask...
</STRONG></P>
<P><STRONG>
And if I find a "Correct"[tm] solution, would you like me to post
it to you for publication in LG? As it may be beneficial to many
people. I will also post it to the maintainer of the Large Disk
HOWTO (<A HREF="http://www.linux-howto.com/LDP/HOWTO/mini/Large-Disk.html"
>http://www.linux-howto.com/LDP/HOWTO/mini/Large-Disk.html</A>)
as well, for inclusion... if I actually get at a solution!
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Actually, Andries Brouwer, maintainer/author of the
LargeDisk mini-HOWTO already has a small section on
the 8Gb Linux IDE limit at:
</BLOCKQUOTE>
<BLOCKQUOTE><BlockQuote>
<A HREF="http://metalab.unc.edu/LDP/HOWTO/mini/Large-Disk-7.html"
>http://metalab.unc.edu/LDP/HOWTO/mini/Large-Disk-7.html</A>
</BlockQuote></BLOCKQUOTE>
<BLOCKQUOTE>
... this could probably use a bit of elaboration.
</BLOCKQUOTE>
<BLOCKQUOTE>
Basically it suggests that recent kernels (2.0.35+ and
2.1.90+) should automatically handle the large drives ---
but that they do a sanity check when the reported LBA
capacity exceeds from the C*H*S by more than a certain
about. Presumably this sanity check is still byting you ---
so it may be that you need to apply his suggested patch.
(That replaces the sanity check with a stub that always
returns the "O.K" value).
</BLOCKQUOTE>
<BLOCKQUOTE>
I suspect that adding the "<tt>linear</tt>" directive to your
lilo.conf (and running <TT>/sbin/lilo</TT> to rebuild the maps
from it --- of course) will solve the problem. If that
doesn't work, try adding appropriate "<tt>disk=</tt>" parameters
to the lilo.conf. Then try this kernel patch.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
There is also a white paper on the so called 8.4 gig limit from
IBM, in case that might also help give you clues... as I'm only
stumped:
</STRONG></P>
<P><STRONG><BlockQuote>
<A HREF="http://www.storage.ibm.com/hardsoft/diskdrdl/library/8.4gb.htm"
>http://www.storage.ibm.com/hardsoft/diskdrdl/library/8.4gb.htm</A>
</BlockQuote></STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
It seems like you did a bit of leg work looking for the
answer (so you get an A+ for effort). However, you probably
should skim over the whole LargeDisk mini-HOWTO (even the
boring parts).
</BLOCKQUOTE>
<BLOCKQUOTE>
Andries does mention the "linear" option in section
6. It's also listed in the lilo.conf man page (big
surprise). Personally I think he might want to
provide a bit more meat, even if it only re-iterates
or repeats what he said earlier. Many people (including
me) will just skip to the section labelled "8Gb IDE Limit."
Some will not understand that they should be trying things
from other sections of the same HOWTO.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Sincerely,
<br>R. Brock Lynn
<br>Debian 2.0
</STRONG></P>
<!-- sig -->
<!-- end 31 -->
<hr width="40%" align="center"><!-- ................................ -->
<!-- begin 36 -->
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
height="50" width="60" alt="(?) " border="0"
>Ultra-DMA and the 8.4Gb IDE Disk Limit</H3>
<p><strong>From R. Brock Lynn on Mon, 18 Jan 1999
</strong></p>
<P><STRONG>
Jim Dennis wrote:
</STRONG></P>
<!-- ::<BlockQuote>
Ultra-DMA and the 8.4Gb IDE Disk Limit
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
</BlockQuote>:: -->
<Pre><STRONG><FONT COLOR="#000099"><EM>
&gt;# df
&gt;Filesystem 1024-blocks Used Available Capacity Mounted on
&gt;/dev/hda5 967677 880562 77116 92% /
&gt;/dev/hda1 1028116 1017468 10648 99% /mnt/c
&gt;/dev/hdb1 8609416 64304 8545112 1% /mnt/bigboy1
&gt;/dev/hdd1 8615982 64304 8551678 1% /mnt/bigboy2
&gt;/dev/sda4 98078 97394 684 99% /mnt/zip
&gt;/dev/hdc 108240 108240 0 100% /mnt/cdrom
</EM></FONT></STRONG></Pre>
<P><STRONG><FONT COLOR="#000066"><EM>
Not quite! You could have <TT>/dev/hdd</TT> --- for a total of
four IDE drives on two channels. I've heard of people
running more than that --- but I think that's just silly.
</EM></FONT></STRONG></P>
<P><STRONG>
Just out of mad curiosity, I wonder if you overlooked the hdd, or
whether I'm overlooking the posibility of one more drive. (I also
have a new IDE CDR I'd like to put in, but according to what I
know, I'd have to take something else out. I think...)
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I don't see hdc on this listing --- so I presume you have
some other OS on it. I was thinking of '<tt>fdisk -l</tt>' output
when I was looking at this.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Hmm, I've got: hda (HD), hdb (HD), hdc (HD), hdd (CD) I think it's
maxed out, but maybe you have a few tricks up your sleeve?
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
No. I was just too tired to be trying to write LG/TAG
stuff when I read your message and tossed off my first
answer.
</BLOCKQUOTE>
<P><STRONG><FONT COLOR="#000099"><EM><IMG
SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
<BR>&gt;The c/h/s numbers printed on both drives:
<tt><BR>&gt;chs: 16383/16/63
<BR>&gt;lba: 19,807,200</tt>
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
Hmm. Those don't add up. But I'm not surprised.
</EM></FONT></STRONG></P>
<P><STRONG>
Yes, I found one solution that seems to have worked to give me the
maximum space on the drives!
</STRONG></P>
<P><STRONG>
I have to give credit to Jason Gunthorpe &lt;<A HREF="mailto:jgg@debian.org"
>jgg@debian.org</A>&gt; of the
<A HREF="http://www.debian.org/">Debian</A> Project for this solution!
(and also several other Debian and non-Debian people on the Open Projects
IRC network.
</STRONG></P>
<P><STRONG>
(I frequently, or rather much more than frequently, "hang out" on
the #debian and #linpeople channels of the irc.openprojects.net
IRC server network, where also quite a few Debian developers and
package maintainers "hang out". My handle is "bytor". Jason's is
"Culus". The main reason I switched to Debian from
<A HREF="http://www.redhat.com/">Red Hat</A> was the
level of support I can get just being in the channel and asking
questions from time to time. And I also help out newbies as
well.
<IMG SRC="../../gx/dennis/smily.gif" ALT=":)"
height="24" width="20" align="middle">
</STRONG></P>
<P><STRONG>
[Actually the system I'm using now is one that I converted in
place from Red Hat 5.0 (upgraded from 4.2) to Debian 2.0. I wrote
up a HOWTO and a tool, a short perl script, to help convert your
passwd/group/shadow files from one system to the other (and all
files on the system to reflect the new uid's/gid's) You can have a
gander if curious at:
</STRONG></P>
<P><STRONG><BlockQuote>
<A HREF="http://www.geocities.com/ResearchTriangle/3328/rh5todeb-howto.txt"
>http://www.geocities.com/ResearchTriangle/3328/rh5todeb-howto.txt</A> and
<A HREF="http://www.geocities.com/ResearchTriangle/3328/conversion-tools.tar.gz"
>http://www.geocities.com/ResearchTriangle/3328/conversion-tools.tar.gz</A>
</BlockQuote></STRONG></P>
<P><STRONG>
Please feel free to include this in anyway at the Answer Guy or
anywhere on Linux Gazette. I will <EM>one day</EM> write it up properly
in SGML, and submit to the LDP... just not enough time
recently. Maybe I should write a short article for LG? (and then
RH would never consider me for a job ever again!)
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
This thread will probably get in there somehow.
</BLOCKQUOTE>
<BLOCKQUOTE>
I'm not sure we need another HOWTO for this issue
--- although you might submit a set of patches and
suggestions to the LargeDisk mini-HOWTO (and I think
we might then upgrade it from a "mini-HOWTO" to a
"full" HOWTO --- though that's a matter for Andries,
Greg Hankins and whoever else is managing LDP HOWTOs
these days.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I hope this doesn't put me in bad standing with the Red Hat guys!
I think Red Hat is great! But I really wanted to try Debian and
didn't have the resources to start fresh! It's working great! I'm
about to do an online "apt-get dist-upgrade" to slink soon using
this very system, the rh--&gt;deb conversion guinea pig.
<IMG SRC="../../gx/dennis/smily.gif" ALT=":)"
height="24" width="20" align="middle">]
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Nobody should apologize for which Linux distribution
they are running.
</BLOCKQUOTE>
<BLOCKQUOTE>
Oh! You're saying you might release a package to
help Red Hat users convert to Debian, and a HOWTO
on that.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Anyhow, here's one more trick to put up your sleeve: (or what
worked for me to make Linux see all of my big harddrives.)
</STRONG></P>
<P><STRONG>
The BIOS/CMOS is messed up anyway. At least mine is. It's several
years old now. It can't handled drives over 8gig(calculated with
1024^n). It autodetects the "correct" numbers that are printed on
the drive. But the numbers printed on the drive are actually
bogus!
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Like Andries and I have said 8Gb is the maximum that
can be expressed in CHS format. However, much larger
capacities can be expressed in LBA ("linear") mode.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
chs: 16383/16/63 (incorrect number of cylinders to match the heads
and sectors per track)
</STRONG></P>
<P><STRONG>
lba: 19,807,200 (this number I believe is the correct number of
total number of sectors though.)
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Yes! You're getting it!
</BLOCKQUOTE>
<BLOCKQUOTE>
LBA stands for "linear block addressing" --- which
needs to be supported by your drive and your OS for it
to work. (I suspect that you also need at least an
EIDE controller).
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Let's see what I've learned!
</STRONG></P>
<P><STRONG>
Total Bytes = [Sectors per track (S)] * [Heads (H)] * [Cylinders (C)]
</STRONG></P>
<P><STRONG>
* [Bytes per sector (512)]
and
</STRONG></P>
<P><STRONG>
Total Bytes = [Total Sectors ("lba" on my drive)] * [Bytes per
sector (512)]
</STRONG></P>
<P><STRONG>
These are good formulas to know... perhaps Andries can add this in
an "appendix" to his HOWTO!
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I think he walks through these calculations a couple
of times already. He doesn't seem to show them in "formula"
format.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Anyhow I can now calculate what the proper number of cylinders
should be based on those formulas. (set both expressions for total
bytes equal, and solve for Cylinders... yep I'm a math egghead.)
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
You don't care what the cylinders/heads and sectors are.
You want to use "linear."
</BLOCKQUOTE>
<Pre><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
[Total Sectors ("lba" on my drive)] * [Bytes per sector (512)]
</STRONG></Pre>
<Pre><STRONG>
Cylinders(C)= -----------------------------------------------------------
[Sectors per track (S)] * [Heads (H)] * [Bytes per sector (512)]
[Total Sectors ("lba" on my drive)]
Cylinders(C)= -------------------------------------
[Sectors per track (S)] * [Heads (H)]
</STRONG></Pre>
<P><STRONG>
for me this is: <tt>C = 19,807,200 <TT>/</TT> (16 * 63 ) = 19650</tt>
</STRONG></P>
<P><STRONG>
(And that is exaclty what Linux sees at boot up, and what fdisk
and cfdisk see ... after the fix Jason Gunthorpe suggeted was
done)
</STRONG></P>
<P><STRONG>
And if I calculate Gigs, from either formula above, I get:
</STRONG></P>
<Pre><STRONG><BlockQuote>
Total Bytes = [Total Sectors ("lba" on my drive)] * [Bytes per sector (512)]
</BlockQuote></STRONG></Pre>
<Pre><STRONG>
= 19,807,200 * 512 = 10141286400 bytes
= ( 10141286400 bytes <TT>/</TT> ( 1024 <EM> 1024 </EM> 1024 bytes/gig )
= 9.44 Gigabytes = 9671.48 Megabytes
</STRONG></Pre>
<P><STRONG>
At boot Linux now sees: <tt>CHS=19650,16,63 9671MB</tt>
and <tt>cfdisk</tt> sees <tt>CHS=19650,16,63 9671.49 MB</tt>
(right on the money!)
</STRONG></P>
<P><STRONG>
(I think fdisk will see CHS=19650,16,63 also, but I was suggested
to use cfdisk instead of fdisk by Jason, as fdisk is no longer
being maintained by the "upstream provider" as Debian calls them.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I blind copied Andries on my message to you and
he pointed out that I should have ignored the CHS
values in the example calculations that I showed.
</BLOCKQUOTE>
<BLOCKQUOTE>
Your ' <TT>fdisk</TT> 'output already shows the correct values.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Mystery unraveled! <EM>Wide Smile</EM>
</STRONG></P>
<P><STRONG>
But I still haven't said how I fixed my system:
</STRONG></P>
<P><STRONG>
Here's what Jason suyggested:
</STRONG></P>
<BlockQuote>
<P><STRONG>
Wipe the partition table:
</P></STRONG>
<P><STRONG><BlockQuote>
either
</BlockQuote></STRONG></P>
<P><STRONG>
"<tt>cat /dev/zero &gt; /hdb</TT>"
</STRONG></P>
<P><STRONG>
and count ten seconds as it blasts away at the drive... you only
need to wipe the first few K
</STRONG></P>
<P><STRONG><BlockQuote>
or
</BlockQuote></STRONG></P>
<P><STRONG>
"<tt>dd if=/dev/zero of=/dev/hdb bs=1024 count=1024</tt>"
</STRONG></P>
</BlockQuote>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Actually a count of one and a block size of 512 bytes
would have been sufficient.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I think that will wipe the first Megabyte of the drive that
supposedly destroys the partition table.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
The partition table is the in the last ~50 bytes of
the master boot record (MBR) which is exactly one sector.
</BLOCKQUOTE>
<BLOCKQUOTE>
That's <EM>all</EM> you need to blow away.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Next, if you have a broken BIOS, like mine, completely disable the
setup for your large drives... Linux will detect them anyway
whether they are listed in the BIOS or not. (At least 2.2.0-pre6
did) I set the "Not installed" flag for both large drives hdb and
hdd in the BIOS.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Hmmm. I think you want to look for an LBA, "linear"
or "PIO" mode for the CMOS IDE settings.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Then I rebooted and BINGO, Linux reports the above CHS=19650,16,63
9671MB for both drives! (before with the BIOS crap enabled, Linux
would see CHS=19650,16,63 for one drive, and CHS=1232,255,63 for
the other drive. Strange I know.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I think the "linear" option would still do the
trick. Most systems won't boot off of a drive that
the CMOS has listed as "not installed"
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
And cfdisk worked for both of them and saw CHS=19650,16,63 9671.49
MB for both drives!
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I think it should have shown that anyway. (Maybe
it needs the "linear" option).
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Next I partitioned each with one large partition, hdb1 and hdd1,
and then formatted with mke2fs: "mke2fs -i 1024 -m 0 <TT>/dev/hdb1</TT>"
</STRONG></P>
<P><STRONG>
-i 1024 is inode density
-m 0 says reserve none for "root only".
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Bad idea! You should reserve a small amount
to lessen the chances of damage to the filesystem
when it gets <EM>full</EM>.
</BLOCKQUOTE>
<BLOCKQUOTE>
Try just 1% on these larger drives. You can use
'tune2fs' to change it (-m to express it as a
percentage, -r to use blocks). You can also set
the "reserved user/group" for that filesystem so
that it's not <EM>just</EM> 'root' that can use the
reserved space on a drive.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
<tt>-c</tt> says to check for bad blocks, which I will do later once I
settle down on a partition table I can live with.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Do it when you first create the partition. Otherwise
some important chunk of data may land on a bad sector
before you remember to do it with '<tt>fsck</tt>'.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Course you know all that... (but I put in here for
documentation... I will write Andries and ask him to add some of
this to his HOWTO.)
</STRONG></P>
<P><STRONG>
It turned out that after the format, using the maximum "Inode
Density" of 1024, (I'm kind of fuzzy in this point but...) I lost
a LOT of space to inode overhead. "df" only saw about 8.2gig
9.44gig - 8.2gig = 1.24gig lost on both disks for a total of
2.48gig lost total!!! ... there was much pulling of hair and
gnashing of teeth at that moment... until I was gently told that
increasing the "inode density" number... that lowers the density,
would help reduce the inode overhead.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Basically each file uses an inode. Any individual file
can use a large number of data blocks. The total number
of inodes and data blocks is set when the filesystem
is created. Additional inodes (extents?) are also allocated
to track indirect blocks (that is blocks of data that are
aren't listed in the first inode --- but are listed on
one of the inodes that links specially them.
</BLOCKQUOTE>
<BLOCKQUOTE>
If you set the ratio wrong you can run out of inodes
when plenty of disk space is available. The filesystem
will still appear to be "full" in that you won't be
able to create new files --- though you'd be able to
append some data to some existing ones until you needed
more of these "extents" (indirect blocks).
</BLOCKQUOTE>
<BLOCKQUOTE>
You can use '<tt>df -i</tt>' to measure the available number of
inodes rather than the number and percentage of datablocks.
</BLOCKQUOTE>
<BLOCKQUOTE>
Basically you should only reduce the inode density if you
know that most of the files will be large --- that you
won't have alot of small files. Even then reducing
it can be a bad idea. It is far more common to increase
the inode density to handle lots of smaller files.
</BLOCKQUOTE>
<BLOCKQUOTE>
Think about it. Every file uses at least one inode.
Multiple hard links don't use additional inodes, they
are additional references to existing inodes. All
file names (directory entries) are links to inodes
(except for some symlinks which can be embedded directly
into ext2 directory structures). So, if you have small
files you run of out inodes faster than when you have
large ones.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I then reformatted with:
</STRONG></P>
<PRE><STRONG><BlockQuote>
mke2fs -i 16384 -m 0
</BlockQuote></STRONG></PRE>
<P><STRONG>
And that time, after mounting the partition, "<tt>df -m</tt>" reported:
9547MB or 9.32gig, so the loss to inode overhead was reduced. (but
of course I risk running out of inodes! So I may redue the inode
number to something in between 1024 and 16384!) But this time the
loss was: 9.44gig - 9.32gig = 0.12gig MUCH better!
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I think that you're cutting it a bit thin. But
let us all know how it works out as the drive gets
some use.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I also have to thank DJ Delorie &lt;<A HREF="mailto:dj@delorie.com"
>dj@delorie.com</A>&gt; (author of the
DJGPP port of gcc to DOS, and the compiler of choice for DOS
Quake) for his kind replies to my email for help as well. He had
posted on the Ask Slashdot thread about large hard drive problems.
</STRONG></P>
<P><STRONG>
He wrote in with the following:
</STRONG></P>
<Pre><STRONG>
-------------------------------------------------------------------
c <EM> h </EM> s * 512 = total bytes
16383 <EM> 16 </EM> 63 * 512 = 8,455,200,768
</STRONG></Pre>
<P><STRONG>
For 10.1g, c would have to be about 19650. The LBA number is the
number of sectors on the disk, so <tt>19,807,200 / (16*63) = 19650</tt>,
which is what you need to tell fdisk.
</STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
Disk <TT>/dev/hdb:</TT> 255 heads, 63 sectors, 1232 cylinders
Disk <TT>/dev/hdd:</TT> 16 heads, 63 sectors, 19650 cylinders
</EM></FONT></STRONG></P>
<P><STRONG>
255 <EM> 63 </EM> 1232 * 512 = 10,133,544,960
16 <EM> 63 </EM> 19650 * 512 = 10,141,286,400
</STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
Anyhow, the darned IBM drives, after formatting only show about
8.2gig. To be precise, here is output of "df": (I included the full
output just in case the
</EM></FONT></STRONG></P>
<P><STRONG>
Don't use df. The capacity it reports is less than the size of the
partition due to the overhead of the ext2 file system (inodes, free
block maps, etc). For example, my 2,096,451 block boot partition
shows 2,028,098 blocks in df.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Yeah. It would be nice if the man page for '<tt>df</tt>'
not only warned you about the overhead but gave
you an idea about the typical percentages to
expect.
</BLOCKQUOTE>
<BLOCKQUOTE>
Heck! It would be even nicer if the '<tt>df</tt>' command
itself offered an option to print the percentage
of overhead in inodes, badblocks, reserved
space, and any other categories that might exist.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
[regarding me being pissed at 10.1gig actually being 9.44gig:]
</STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
That makes me MAD! Theses guys are the cream of the crop... they
<EM>make</EM> the hardware, they should know and use the proper "1024"
rather than the 1000 multiplier! ooh that strikes a nerve! Anyhow...
</EM></FONT></STRONG></P>
<P><STRONG>
Seagate always uses the 1000^n values, so you get what you expect.
Most manufacturers tell you which measure they use.
</STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
But later I found out that -i 1024 was not the "cluster size" but
rather inode density and increasing it to say 10240 would help cut
down on the overhead of all the inodes and give me more space
according to Jason. Haven't tried, but will soon. (but I fear
running out of inodes... will have to experiment)
</EM></FONT></STRONG></P>
<P><STRONG>
"inode density" is tech speak for "average file size". If you know
how big the average file will be, you can make it so that you run out
of space and inodes at about the same time.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
That's a great simplication. It's absolutely true and
doesn't explain the mechanism at all.
</BLOCKQUOTE>
<P><STRONG><FONT COLOR="#000066"><EM><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Yes, I plan to make a 10 to 20 meg <TT>/boot</TT> partition just for kernels
at the front of the drive... I hope 20 meg is small enough to fit
under the 1024th cylinder!
</EM></FONT></STRONG></P>
<P><STRONG>
Your kernel is only 1Mb. One cylinder (~8Mb on most big drives)
should be plenty.
</STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
Heh, perhaps I can sue IBM or the vendor in a local court in my
hometown? over the difference between 1024 and 1000. And show that
1000 is not the proper multiplier in the world of computers? If
nothing else just to prove a point that consumers don't like to be
lied to!
</EM></FONT></STRONG></P>
<P><STRONG>
Many catalogs explicitly state "1Gb=1000Mb" somewhere, to tell you
which measure they use. Both are equally likely.
</STRONG></P>
<P><STRONG>
Which helped!
</STRONG></P>
<P><STRONG><FONT COLOR="#000099"><EM>
<BR>&gt;I wish I knew how to calculate total space in megs using C/H/S numbers!
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
Sectors are 512 bytes. You multiple cylinders (C), heads
(H), and sectors per track (S) to get the total number of
sectors. Think of track as one head on one cylinder. That
is to say that it is one concentric ring on one side of
one platter.
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
That's all really a fiction since all of the high capacity
drives in the last decade (everything over about 200Mb)
have used "ZBR" (zone bit recording) and consequently don't
physically have the same number of sectors per track out
the outer "zones" (rings) of the platters as they do on
the inner zones.
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
The drive electronics hide these details from the rest
of the hardware so that the BIOS can "pretend" that it
really is an even number of sectors on a given number of
heads with a given number of tracks. The drives (SCSI and
IDE) will "auto translate" into BIOS compatible disk
addresses (CHS). (Actually SCSI controllers usually
replace the BIOS routines that handle this --- but
effectively the drive is still abstracting most of the
details away from the controller and the OS).
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
The BIOS was only set to handle 10 bits of cylinder (1024
maximum), six bits of sector (per track) and eight bits
of "head" which fits neatly into a 16 bit register and
one byte register. Those were convenient for programming
the 8086 based systems that were common about 20 years ago.
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
(They're pretty silly now).
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
In any event the famed 8Gb limit is derived from
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
&quot;
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
max cylinders <EM> max sectors </EM> max heads
= maximum total sectors
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
or:
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM><BlockQuote>
1024 <EM> 64 </EM> 255 = 16777216
&quot;
</BlockQuote></EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
which we convert to Kilobytes, Megabytes and Gigabytes
by:
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM><BlockQuote>
&quot;
16777216 <TT>/</TT> 2 = 8388608 (maximum total K)
</BlockQuote></EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
<TT>/</TT> 1000 = 8388 (maximum total Mb)
<TT>/</TT> 1000 = 8.4 (maximum total Gb)
&quot;
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
... note that we don't use 1024 to compute Mb and Gb.
This is common practice among drive manufacturers (and
unheard of for memory chips). That has been a matter of
some controversy as those extra 24 K per Mb start to had up
when you're doing them by the thousand.
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
I won't pretend to be authoritative on that subject.
Let's suffice to say that given the original contraints
of the BIOS addressing system the maximum addressable space
(in 512 byte sectors) is between 8 and 8.4 Gb (depending
on how you calculate your Gigabytes).
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
Over the years there have been various other limitation
with parts of that. This trick of lying about the number
of "heads" and claiming that there were 255 heads was
the earliest way to over come the "1024 cylinder problem"
--- which had lead to the early "540Mb" limit on IDE
drives. Various different ways of accomplishing this were
labelled EIDE and ATA-2. We no have ATA-3 and UltraDMA.
</EM></FONT></STRONG></P>
<P><STRONG>
Thanks a TON for the above information! Very helpful stuff!
</STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
The drive's electronics will take all of the parts of any
address (CHS) that are presented to it and multiply them
all together to get a "linear block address" (LBA). So
It really doesn't matter what your CMOS says.
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
However, you probably have to add lilo.conf directives
to pass the drive's true "geometry" to the kernel
(so it will ignore the CMOS values).
</EM></FONT></STRONG></P>
<P><STRONG>
I was pondering doing that, instead of twidling with with
disabling the drives in the BIOS. As I <EM>might</EM> heaven help me,
want to put NT, *BSD, Solarisx86, or BeOS on the drives as well,
and they might require a BIOS entry!
</STRONG></P>
<P><STRONG>
I suppose now that I have the correct "bogus" geometries, I can
add that in lilo as:
<br>' <tt>append = "hdb=19650,16,63 hdd=19650,16,63</tt>"
'
</STRONG></P>
<P><STRONG>
And then maybe reenable the BIOS entries? (Jason suggested once I
got the drives partitioned and formatted correctly I might be able
to reenable the BIOS settings so that DOS or other OS's would be
able to see it... not sure on that though. But he warned me that
possibly cfdisk or fdisk might not partition the drive to where
the partition boundaries would land at places where DOS, NT, or
other OS's might expect them to.
</STRONG></P>
<P><STRONG>
Another thing that was suggested by Jason, (something he says he's
done before) is to take the drive to someone with a PentiumII MB
(assuming they have a working BIOS) and partition with DOS
fdisk. So you know the partition table is acceptable to DOS style
OS's. (in case you ever have a need to fool with such things.)
Then take the drive back to your broken BIOS computer, and then
change the partiton types to Linux and Linux Swap, but not
changing the boundaries. (dunno if you have to disable the BIOS
entries of not first) and then it should *work*!
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
That's good advice. Think about doing a BIOS
upgrade for yourself, too.
</BLOCKQUOTE>
<P><STRONG><FONT COLOR="#000099"><EM><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
<BR>&gt;Perhaps you can help investigate this further, and finally put
<BR>&gt;this problem to rest once and for all in the annals of Linux
<BR>&gt;Gazette!
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000099"><EM>
<BR>&gt;And if I find a "Correct"[tm] solution, would you like me to post
<BR>&gt;it to you for publication in LG? As it may be beneficial to many
<BR>&gt;people. I will also post it to the maintainer of the Large Disk
<BR>&gt;HOWTO (<A HREF="http://www.linux-howto.com/LDP/HOWTO/mini/Large-Disk.html"
<BR>&gt; >http://www.linux-howto.com/LDP/HOWTO/mini/Large-Disk.html</A>)
<BR>&gt;as well, for inclusion... if I actually get at a solution!
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
Actually, Andries Brouwer, maintainer/author of the
LargeDisk mini-HOWTO already has a small section on
the 8Gb Linux IDE limit at:
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM><BlockQuote>
<A HREF="http://metalab.unc.edu/LDP/HOWTO/mini/Large-Disk-7.html"
>http://metalab.unc.edu/LDP/HOWTO/mini/Large-Disk-7.html</A>
</BlockQuote></EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
... this could probably use a bit of elaboration.
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
Basically it suggests that recent kernels (2.0.35+ and
2.1.90+) should automatically handle the large drives ---
but that they do a sanity check when the reported LBA
capacity exceeds from the C*H*S by more than a certain
about. Presumably this sanity check is still byting you ---
so it may be that you need to apply his suggested patch.
(That replaces the sanity check with a stub that always
returns the "O.K" value).
</EM></FONT></STRONG></P>
<P><STRONG>
Ah, I will look into that. If I reenable the BIOS entries and
Linux starts to see funny values again, I'll try it.
</STRONG></P>
<P><STRONG>
I haven't had a working windows partition on my system for over a
year now. I love Linux, but since I have all the space now with
the new drives I decided I might want to try NT... the main
interest being to experiment with Cygwin to get a Unix-like layer
working for NT (in case I ever have a job with NT servers, I'll
have experience in Unix-ifying them
<IMG SRC="../../gx/dennis/smily.gif" ALT=";)"
height="24" width="20" align="middle">
</STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
I suspect that adding the "linear" directive to your
lilo.conf (and running <TT>/sbin/lilo</TT> to rebuild the maps
from it --- of course) will solve the problem. If that
doesn't work, try adding appropriate "disk=" parameters
to the lilo.conf. Then try this kernel patch.
</EM></FONT></STRONG></P>
<P><STRONG>
Hmm, I'm not familiar with the reasoning behind the "linear"
option. I seem to recall all SCSI disks need it? May try it also
and see what happens. Is "linear" a global option to lilo, that
affects all disks in the system, or a per disk option? I think it
is global, but I'm not sure. And if global, would it adversely
affect the smaller drives that have, up till now, worked well w/o
that option? I'll have to investigate this.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
It's listed in "Global Option" section of the
man page. But I'm not sure.
</BLOCKQUOTE>
<P><STRONG><FONT COLOR="#000099"><EM><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
<BR>&gt;There is also a white paper on the so called 8.4 gig limit from
<BR>&gt;IBM, in case that might also help give you clues... as I'm only
<BR>&gt;stumped:
</EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000099"><EM><BlockQuote>
<BR>&gt;<A HREF="http://www.storage.ibm.com/hardsoft/diskdrdl/library/8.4gb.htm"
>http://www.storage.ibm.com/hardsoft/diskdrdl/library/8.4gb.htm</A>
</BlockQuote></EM></FONT></STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
It seems like you did a bit of leg work looking for the
answer (so you get an A+ for effort). However, you probably
should skim over the whole LargeDisk mini-HOWTO (even the
boring parts).
</EM></FONT></STRONG></P>
<P><STRONG>
Well, thanks for the commendation.
<IMG SRC="../../gx/dennis/smily.gif" ALT="8-)"
height="24" width="20" align="middle">
</STRONG></P>
<P><STRONG>
I've just <EM>got to know</EM> the real answer! I'll go to almost any
length to get at "what's really going on"
<IMG SRC="../../gx/dennis/smily.gif" ALT=":)"
height="24" width="20" align="middle">
</STRONG></P>
<P><STRONG><FONT COLOR="#000066"><EM>
Andries does mention the "linear" option in section
6. It's also listed in the lilo.conf man page (big
surprise). Personally I think he might want to
provide a bit more meat, even if it only re-iterates
or repeats what he said earlier. Many people (including
me) will just skip to the section labelled "8Gb IDE Limit."
Some will not understand that they should be trying things
from other sections of the same HOWTO.
</EM></FONT></STRONG></P>
<P><STRONG>
Yes, I have to admit I didn't read the whole thing, I skimmed a
bit and focused on that short section. I'll give it another look,
this time reading it carefully, and if I see that any of the
things above are missing, I'll prepare and email, and send it off
to him for inclusion in the next version.
</STRONG></P>
<P><STRONG>
Also, one other thing that I can do is try the Ontrack Disk
Manager software for the IBM drives. It's similar to EZDrive, and
is supported by Linux... only someone told me it wasn't supported
by <A HREF="http://www.freebsd.org/">FreeBSD</A>... and I want to expriement with it. As I was told this
Ontrack disk manager install to the boot drive, even if it's not
the drive that needs it. And gets loaded at boot time, before even
the lilo code in the MBR gets called. It supposedly replaces the
BIOS disk routines. This may be the better solution for Linux and
NT but not if I want to try one of the BSD's. I will have to look
more into this also.
</STRONG></P>
<P><STRONG>
I remember back when I needed EZDrive with my 486 to recognize the
full 540meg drive I had back then. And was suprised when Linux
detected and dealt with EZdrive properly!
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
I was surprised when they added the support for OnTrack
EZDrive and a few others, too.
</BLOCKQUOTE>
<BLOCKQUOTE>
I still won't go near them. But its nice to know
that we <EM>can</EM>.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Thanks for your reply! Will you write up an "Answer Guy" section
detailing this question <TT>/</TT> problem in the next LG, or is it too
involved?
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
It's certainly not my longest or most complicated thread.
However, writing it up in a more organized fashion, as an
LG article and as a set of suggested enhancements to
the mini-HOWTO..
</BLOCKQUOTE>
<blockquote><em>[
Once Jim's written it, it stays in. The only messages or
threads I ever toss out completely are some with no Linux
in them. But I do sometimes defer confusing threads until
the next issue, so I can spend the first week of a month
polishing them so they don't make me dizzy. This one's
pretty close, but I think it'll do alright.
-- Heather ]
</em></blockquote>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
R. Brock Lynn
</STRONG></P>
<!-- sig -->
<!-- end 36 -->
<!--startcut ======================================================= -->
<P> <hr> <P>
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
>Copyright &copy;</a> 1999, James T. Dennis
<BR>Published in <I>The Linux Gazette</I> Issue 37 February 1999</H5>
<P> <hr> <P>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<P align="center">
<table width="98%"><tr valign="center" align="center">
<td rowspan="3" colspan="4"><A HREF="../lg_answer37.html"><IMG
SRC="../../gx/dennis/answernew.gif"
ALT="[ Answer Guy Index ]"></A></td>
<TD width="8%"><A HREF="./1.html">1</A></TD>
<TD width="8%"><A HREF="./2.html">2</A></TD>
<TD width="8%"><A HREF="./3.html">3</A></TD>
<TD width="8%"><A HREF="./4.html">4</A></TD>
<TD width="8%"><A HREF="./5.html">5</A></TD>
<TD width="8%"><A HREF="./6.html">6</A></TD>
<TD width="8%"><A HREF="./7.html">7</A></TD>
<TD width="8%"><A HREF="./8.html">8</A></TD>
<TD width="8%"><A HREF="./9.html">9</A></TD>
<TD width="8%"><A HREF="./10.html">10</A></TD>
</tr><tr valign="center" align="center">
<TD><A HREF="./11.html">11</A></TD>
<TD><A HREF="./12.html">12</A></TD>
<TD><A HREF="./14.html">14</A></TD>
<TD><A HREF="./15.html">15</A></TD>
<TD><A HREF="./16.html">16</A></TD>
<TD><A HREF="./17.html">17</A></TD>
<TD><A HREF="./18.html">18</A></TD>
<TD><A HREF="./19.html">19</A></TD>
<TD><A HREF="./21.html">21</A></TD>
<TD><A HREF="./22.html">22</A></TD>
</tr><tr valign="center" align="center">
<TD><A HREF="./23.html">23</A></TD>
<TD><A HREF="./28.html">28</A></TD>
<TD><A HREF="./29.html">29</A></TD>
<TD><A HREF="./30.html">30</A></TD>
<TD><A HREF="./31.html">31</A></TD>
<TD><A HREF="./32.html">32</A></TD>
<TD><A HREF="./33.html">33</A></TD>
<TD><A HREF="./34.html">34</A></TD>
<TD><A HREF="./37.html">37</A></TD>
<TD><A HREF="./38.html">38</A></TD>
</tr><tr valign="center" align="center">
<TD><A HREF="./39.html">39</A></TD>
<TD><A HREF="./41.html">41</A></TD>
<TD><A HREF="./42.html">42</A></TD>
<TD><A HREF="./43.html">43</A></TD>
<TD><A HREF="./44.html">44</A></TD>
<TD><A HREF="./45.html">45</A></TD>
<TD><A HREF="./46.html">46</A></TD>
<TD><A HREF="./47.html">47</A></TD>
<TD><A HREF="./48.html">48</A></TD>
<TD><A HREF="./49.html">49</A></TD>
</tr></table>
</P>
<P> <hr> <P>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<P> <hr> <P>
<!-- begin lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<A HREF="../index.html"
><IMG SRC="../../gx/indexnew.gif" ALT="[ Table Of Contents ]"></A>
<A HREF="../../index.html"
><IMG SRC="../../gx/homenew.gif" ALT="[ Front Page ]"></A>
<A HREF="../lg_bytes37.html"
><IMG SRC="../../gx/back2.gif" ALT="[ Previous Section ]"></A>
<A HREF="../york.html"
><IMG SRC="../../gx/fwd.gif" ALT="[ Next Section ]"></A>
<!-- end lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
</BODY></HTML>
<!--endcut ========================================================= -->
Reference in New Issue View Git Blame Copy Permalink