pitiful performance of an SATA150 drive

[Søren Schmidt]

Mikhail Teterin wrote:
> Over a year later this remains a problem -- exactly as described below...
>
> No other SATA devices are present -- the only other IDE device is the DVD 
> drive. My main disks are SCSI.
>
> What's MUCH worse is that the (slowly) written data is also often corrupted... 
> I use the drive to store our vast collection of photos and the backups. Every 
> once in a while I encounter a corrupt JPEG file, and the backups are _always_ 
> corrupt somewhere. Doing something like:
>
> 	dump 0auChf 16 0 - /home | bzip2 -9 > /store/home.0.bz2
>
> always produces a corrupt file (as per ``bzip2 -t''). I used to blame the 
> drive's temperature, but it now sits in its own enclosure and stays under 40 
> Celsius.
>
> When the drive is accessed, there are (according to `systat -vm') many 
> thousands of interrupts 17 -- on my system these are shared between pcm0 and 
> ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's 
> share of the CPU time is often above 80% of one processor's total (I have 4 
> processors).
>
> As I mentioned a year ago, Knoppix was accessing the same drive at much higher 
> speeds, so I don't believe, the problem is with the hardware...
>   
What HW was this again, there has been alot of updates/changes over the 
last year ?
Could you try an up to date -current kernel on this, at least to get me 
a decent dmesg from ?
If thats impossible take ATA from current modulus the busdma changes and 
use that on an up to date 6-stable.
I cant tell what interrupts go where without a dmesg...

Other than that, single bit/byte corruption are normally HW troubles of 
some kind, usually involving bad/incompatible memory or bad chipsets.
However, if your drive has been overheated the media might have taken 
permanent damage that makes it loose data.
What does SMART say on corrected errors etc (if the drive has that info).

-Søren
> Please, advise. Thanks!
>
> 	-mi
>
> On Wednesday 01 March 2006 11:07, Mikhail Teterin wrote:
> = On Wednesday 01 March 2006, Søren Schmidt wrote:
> = = dd if=/dev/ad8 of=/dev/null bs=1m
> = 
> = Well, as I said, there is no obvious problems with _reading_. The above 
> = command reads at well over 60Mb/s:
> = 
> = 	1638924288 bytes transferred in 25.374856 secs (64588516 bytes/sec)
> = 
> = _Writing_, however, remains pathetic:
> = 
> = 	dd of=/dev/ad8 if=/dev/zero bs=1m
> = 	631242752 bytes transferred in 91.039066 secs (6933757 bytes/sec)
> = 
> = = The problem is the blocksize that gets in the way of utilizing full
> = = transfer speed.
> = 
> = Did you really expect the blocksize to make an order of (decimal) magnitude 
> = difference? :-) It made no difference at all :-(
> = 
> = Brian Candler asked:
> = = Just to be clear: this is Knoppix running on the *same* machine as you've
> = = been testing FreeBSD?
> = 
> = Correct.
> = 
> = = Aside: why are you using cat under FreeBSD, but dd under Knoppix? I'd use 
> dd
> = = everywhere for consistency.
> = 
> = Cat was slightly faster in my tests on FreeBSD. I used dd under Knoppix for 
> = dd's throughput reporting -- I'm not aware of a monitoring tool like 
> `systat' 
> = under Linux.
> = 
> = Yours,
> = 
> = 	-mi
> = 
>
> .
>
>