Date: Mon, 26 Mar 2007 14:36:27 -0400 From: Mikhail Teterin <mi+kde@aldan.algebra.com> To: =?iso-8859-1?q?S=F8ren_Schmidt?= <sos@deepcore.dk> Cc: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>, stable@freebsd.org, Derek Ragona <derek@computinginnovations.com>, Brian Candler <B.Candler@pobox.com> Subject: Re: pitiful performance of an SATA150 drive Message-ID: <200703261436.28659@aldan> In-Reply-To: <200603011107.09942@aldan> References: <200603010505.k2155HfQ003205@aldan.algebra.com> <44054C5E.5070902@deepcore.dk> <200603011107.09942@aldan>
next in thread | previous in thread | raw e-mail | index | archive | help
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... 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 =
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703261436.28659>