Re: [ale] Just an FYI for those using UDMA hard drives and RH 7.2
Michael Smith
msmith at mikeandmel.com
Tue Jan 15 15:54:56 EST 2002
This situation has really made me take a closer look at SCSI. I can
appreciate the speed and cost of the new UDMA IDE drives but I think you
end up getting short changed in the quality department. I think hard
drives have taken the route of some American cars(no flame intended).
We'll make it high speed but you have to pay the price in quality. I am
going to see how the drives I have hold up(along with weekly backups), but
the next CRC error I get will put me on pricewatch.com looking for a new
SCSI controller and hard drive......
> Yep, that's why scsi is much faster. It still has the always-on CRC,
> but it is done in hardware. IDE does it in software. So each write
> includes a call back up the bus to the cpu with a "please check this?"
> request. The scsi write package includes the crc in the datagram (I
> think) so the hardware on the drive does the readback/crc test. While
> the overall size of IDE drives has far surpassed the scsi crowd, it
> hasn't come close to the speed or long-term reliability of scsi.
>
> Just look at the warranties for IDE drives. Most are 1 year, some are 3
> years. SCSI drives are 5 years.
>
> "But, you can buy 2 ide drives for the price of the same size scsi and
> just replace it if it dies". Yes, but then I have to also replace what
> was on the drive and that is the PIA part even with good backups.
>
> Also most speed numbers for IDE are reads, not writes. Now we know why.
>
> On Tue, 2002-01-15 at 14:13, jeff hubbs wrote:
>> OK, I follow you now. This puts the situation in a much different
>> light.
>>
>> Is this a lingering reason to avoid IDE drives when speed matters or
>> is this par for the course under SCSI as well? My old paradigm was
>> to avoid IDE as much as possible but I changed my tune a bit once IDE
>> performance started getting much better price-performance-wise.
>>
>> - Jeff
>>
>> James P. Kinney III wrote:
>>
>> > As I see it, Maxtor has chosen to inflate their performance by
>> > disabling the write verification CRC check. The WV-CRC is the normal
>> > process for hard drives. That's why with it turned off, the ide
>> > controller software would crash. It is always expecting the CRC
>> > reply. In this case, it wasn't getting one at all, so it assumed the
>> > writes were failing.
>> >
>> > I think this should be noted to the kernel mailing list as a
>> > heads-up to a "feature/bug" from Maxtor. The real headache is that
>> > Maxtor seems to opt for speed with out notifying the user that the
>> > normal mode of operation will change forever.
>> >
>> > On Tue, 2002-01-15 at 13:28, jeff hubbs wrote:
>> >
>> >>Is this something for the kernel development list? Having to take a
>> >> permanent performance hit doesn't strike me as a good solution.
>> >>Does it seem as though Maxtors are the only affected drives?
>> >>
>> >>- Jeff
>> >>
>> >>James P. Kinney III wrote:
>> >>
>> >>
>> >>>What an arcane problem! Congratulations on getting it resolved.
>> >>>That took some legwork.
>> >>>
>> >>>I can see the reasons for having the option to turn off WV. I take
>> >>>it it was not documented with the drive. It seems a bit underhanded
>> >>>if the WV is turned off for benchmarking but will fail under normal
>> >>>conditions with out it.
>> >>>
>> >>>So, clearly, RedHat 7.2, and presumably Linux in general, will have
>> >>>a hard time with this drive unless WV is always on. Is a write
>> >>>verify CRC check manadatory at all times? Is there an option in
>> >>>/proc/ide that will allow the WV to be turned off from the Linux OS
>> >>>for speed trials? Does this drive come with an installation disk
>> >>>for M$?
>> >>>
>> >>>I don't use any Maxtor drives so my proc shows no WV parameters. I
>> >>>went digging in "man hdparm" and found a -W flag that is used to
>> >>>toggle the write caching. No reference to write verify.
>> >>>
>> >>>On Tue, 2002-01-15 at 12:08, Michael Smith wrote:
>> >>>
>> >>>
>> >>>>I have been fighting for the last 2 weeks trying to get my 7.2
>> >>>>machine up for more than 12 hours at a time without a kernel
>> >>>>panic and I think I finally got it working...
>> >>>>
>> >>>>I determined that it was a UDMA issue after receiving
>> >>>>{DriveStatusError BadCRC} errors in the messages log file. So I
>> >>>>bought 2 new 80 pin, less than 18 inch, ide cables after reading
>> >>>>this blurb at
>> >>>>http://www.kernel.org/pub/linux/docs/lkml/#s13-3 . I still
>> >>>>received the errors. So I then moved the hard drives to the
>> >>>>bottom and top bays to hopefully reduce any crosstalk. Still
>> >>>>didn't work. I then moved the power cables as far away from the
>> >>>>ide cables as possible. Still didn't work.
>> >>>>
>> >>>>So now I am thinking that either my controller or my hard drives
>> >>>>are bad. I go to the Maxtor site and download Powermax to test
>> >>>>the drives. I perform exhaustive checks with both drives coming
>> >>>>out without any errors. I am now at a loss.
>> >>>>
>> >>>>So I dig a little more on the Maxtor site about the write verify
>> >>>>functionality on the hard drive and find out, that for speed, the
>> >>>>write verify is turned off after 10 power cycles on the hard
>> >>>>drive. So I downloaded this utility called WVSet from their site
>> >>>>and turned the write verify back on permanently and now my
>> >>>>machine has been up for 24 hours w/o a kernel panic....
>> >>>>
>> >>>>Here's Maxtor's blurb on Write Verify:
>> >>>>
>> >>>>"Write Verify" performs a Read of the data just written to the
>> >>>>hard drive and validates the data via the Cyclic Redundancy Check
>> >>>>(CRC), providing additional assurance that the data written to
>> >>>>the hard drive was written correctly. When Write Verify is
>> >>>>enabled, the WRITE performance of the drive is affected as a read
>> >>>>occurs for each write. When disabled WRITE performance is
>> >>>>improved as, a read is not performed for each write When
>> >>>>performing benchmark operations the "write verify" feature should
>> >>>>be disabled to insure valid comparisons to other products that do
>> >>>>not offer this capability in their product.
>> >>>>
>> >>>>
>> >>>>Just an FYI......
>> >>>>
>> >>>>--
>> >>>>Michael Smith
>> >>>>
>> >>>>
>> >>>>
>> >>>>---
>> >>>>This message has been sent through the ALE general discussion
>> >>>>list. See http://www.ale.org/mailing-lists.shtml for more info.
>> >>>>Problems should be sent to listmaster at ale dot org.
>> >>>>
>> >>>>
>> >>>>
>> >>
>> >>
>> >>
>> >>---
>> >>This message has been sent through the ALE general discussion list.
>> >>See http://www.ale.org/mailing-lists.shtml for more info. Problems
>> >>should be sent to listmaster at ale dot org.
>> >>
>> >>
>>
>>
>>
>>
>> ---
>> This message has been sent through the ALE general discussion list.
>> See http://www.ale.org/mailing-lists.shtml for more info. Problems
>> should be sent to listmaster at ale dot org.
>>
> --
> James P. Kinney III \Changing the mobile computing world/
> President and COO \ one Linux user /
> Local Net Solutions,LLC \ at a time. /
> 770-493-8244 \.___________________________./
>
> GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
> <jkinney at localnetsolutions.com>
> Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7
--
Michael Smith
msmith at mikeandmel.com
---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.
More information about the Ale
mailing list