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
=
.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
