[ale] Just an FYI for those using UDMA hard drives and RH 7.2

Tue Jan 15 14:41:06 EST 2002

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 

 PGP signature