by Daniel Feenberg
Except for the most recent kernels, Linux will only see 137 GB out of
the 156 GB on the the Maxtor "160 Gigabyte" Diamondmax 540T drives. I
found nothing on the Maxtor or RedHat web sites about this, but a search
of the Linux Kernel mailing list produced a number of references to a
patch which was purported to work by some people. Some additional
available here but for those unwilling or unable to patch their
kernel, it is possible to simply upgrade to the latest release if you are
using the Redhat distribution.
Redhat 7.2 will see only 137 GB, but RH 7.3 will see the entire drive.
Which comes to 156 GB of usable space. I don't know about the other
distributions, but I guess that any based on Kernel 2.4.18-3 or better
will be much the same. Somewhere between 2.4.7-10 and 2.4.18-3 the patch
may have been accepted into the standard kernel, or perhaps RH just added
it to its distribution. It may be in other distributions, also. I'd like
to hear from someone who actually knows.
There is some discussion on the Linux Kernel mailing list about which
IDE controllers will support the larger drives and some posters alleged
BIOS compatibility problems on older motherboards. The most knowledgable
participants in the debate say that all controllers will work and there
are no BIOS issues.
In my experiments the first two channels on a relatively new Gigafast
GA-7/DXR motherboard did support the large partition, but two additional
motherboard connectors intended for RAID arrays (Promise Technology
MBFasTtrak133) did not. A call to the vendor informed me that the 3rd and
4th connectors required a special Linux driver to operate at all, but that
PCI based IDE controllers would be supported by any kernel.
I prefer buying new hardware to modifying the kernel. So I bought a
Maxtor Ultra100 controller, which did not work (the boot failed at the
"Partition check" stage), and later a Maxtor Ultra133 (also called
Ultra133TX2 and sometimes bundled with the drive in retail packages)
controller, which did work. This leaves me agreeing with the other
clueless users who think that a controller claiming compatibility with the
Maxtor 133 megabit/second standard is required and contradicts the wisdom
of the cluefull. These controllers include some BIOS code, which might
also be helpfull. I did find a press
release from Promise Technology claiming that there was a new standard
for 48-bit addressing of IDE drives, called "Big Drive". Maxtor doesn't
mention that on the box, or in the docs supplied with the controller or
The RH default partitions generated by the Redhat 7.3 partitioning tool
(as invoked by the initial installation program) are unsuitable for drives
so large, so you probably want to do the partitioning yourself.
Interestingly enough Disk Druid saw 156,327MB (19,929 cylinders) on 4 of
the drives and 156,334 MB (19,930 cylinders) on the other two. And no, it
didn't seem to matter which controller or which partition program was
We are using this as JBOD, so we did not consider it necessary to
restrict ourselves to one drive per IDE cable.
The drives consume about 16 watts each at startup and about 6 watts
each in steady state. (We have a meter). Even with no special cooling they
do not get hot. The entire box with 6 160 Gigabyte drives consumes 225
watts at start up and 125 watts steady state. I wound up with 885 (true)
gigabytes of user file storage for about $2,500.
Introductory Linux documentation doesn't cover adding a hard drive to
an existing system, but it is quite easy to do with the sfdisk command.
The e2label command is optional, but is used with the new scheme of
mounting partitions by Label rather than device name.
#e2label /dev/hdc /mountpoint
and accept every default to get the entire disk assigned to
partition 1. Then add one of the following two lines to /etc/fstab:
/dev/hdc1 /mountpoint ext3 defaults 1 1
LABEL=/mountpoint /mountpoint ext3 defaults 1 1
Of course you only get the full disk if you start with RH 7.3. The ext2
filesystem will automatically be converted to ext3 when mounted for the
first time. These would take a long time to fsck if you actually used an
[With thanks to Alex Aminoff]
An updated copy of this memo is kept at http://www.nber.org/sys-admin/maxtor-160.html.