[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] Qube3 - Speed Increase
- Subject: Re: [cobalt-users] Qube3 - Speed Increase
- From: Parker Morse <morse@xxxxxxxxxxx>
- Date: Mon Sep 23 07:45:01 2002
- List-id: Mailing list for users to share thoughts on Sun Cobalt products. <cobalt-users.list.cobalt.com>
On Sunday, September 22, 2002, at 05:30 AM, Sonny Taite wrote:
On 9/22/02 7:41 PM, "Sonny Taite" <sonny@xxxxxxxxx> wrote:
THE USUAL WARNINGS :: USE AT YOUR OWN RISK - NO RESPONSIBILITY TAKEN BY
ME
OR ASSOCIATES OF ME FOR LOSS OF INFORMATION.
> /sbin/hdparm -X66 -d1 -m16 -c3 /dev/hda
I'm intrigued, but I wanted to look before I leapt. So I ran
$ man hdparm
and found the following warnings; for -X66:
mode2 transfers (you'll need to prepare the chipset
for UltraDMA beforehand). Apart from that, use of
this flag is seldom necessary since most/all modern
IDE drives default to their fastest PIO transfer
mode at power-on. Fiddling with this can be both
needless and risky. On drives which support alter-
nate transfer modes, -X can be used to switch the
mode of the drive only. Prior to changing the
transfer mode, the IDE interface should be jumpered
or programmed (see -p flag) for the new mode set-
ting to prevent loss and/or corruption of data.
Use this with extreme caution! For the PIO (Pro-
and for -m16:
output). Some drives claim to support multiple
mode, but lose data at some settings. Under rare
circumstances, such failures can result in massive
filesystem corruption.
However, it has clearly worked for Sonny.
Bearing in mind that many of us - particularly Qube users - ARE appliance
operators and thirsty for enlightenment, can someone expand on why this
might (or might not) be a worthwhile risk to take? I can easily believe
that Sun would ship the Qube without this sort of optimization, but I have
a harder time believing that I know the hardware better than they do. :-)
Thanks,
pjm