From owner-freebsd-stable@FreeBSD.ORG Mon Mar 26 19:26:28 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A05E216A401 for ; Mon, 26 Mar 2007 19:26:28 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.freebsd.org (Postfix) with ESMTP id 2177D13C455 for ; Mon, 26 Mar 2007 19:26:27 +0000 (UTC) (envelope-from sos@deepcore.dk) Received: from [194.192.25.137] (ws.deepcore.dk [194.192.25.137]) by spider.deepcore.dk (8.13.8/8.13.8) with ESMTP id l2QJLZlN077301; Mon, 26 Mar 2007 21:21:35 +0200 (CEST) (envelope-from sos@deepcore.dk) Message-ID: <46081D3E.5070204@deepcore.dk> Date: Mon, 26 Mar 2007 21:21:34 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Mikhail Teterin References: <200603010505.k2155HfQ003205@aldan.algebra.com> <44054C5E.5070902@deepcore.dk> <200603011107.09942@aldan> <200703261436.28659@aldan> In-Reply-To: <200703261436.28659@aldan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Dmitry Pryanishnikov , stable@freebsd.org, Derek Ragona , Brian Candler Subject: Re: pitiful performance of an SATA150 drive X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2007 19:26:28 -0000 Mikhail Teterin wrote: > Over a year later this remains a problem -- exactly as described below.= =2E. > > No other SATA devices are present -- the only other IDE device is the D= VD=20 > drive. My main disks are SCSI. > > What's MUCH worse is that the (slowly) written data is also often corru= pted...=20 > I use the drive to store our vast collection of photos and the backups.= Every=20 > once in a while I encounter a corrupt JPEG file, and the backups are _a= lways_=20 > 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 t= he=20 > drive's temperature, but it now sits in its own enclosure and stays und= er 40=20 > Celsius. > > When the drive is accessed, there are (according to `systat -vm') many = > thousands of interrupts 17 -- on my system these are shared between pcm= 0 and=20 > ehci0. Why are these triggered by accessing SATA is unclear, but the In= tr's=20 > share of the CPU time is often above 80% of one processor's total (I ha= ve 4=20 > processors). > > As I mentioned a year ago, Knoppix was accessing the same drive at much= higher=20 > speeds, so I don't believe, the problem is with the hardware... > =20 What HW was this again, there has been alot of updates/changes over the=20 last year ? Could you try an up to date -current kernel on this, at least to get me=20 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=20 some kind, usually involving bad/incompatible memory or bad chipsets. However, if your drive has been overheated the media might have taken=20 permanent damage that makes it loose data. What does SMART say on corrected errors etc (if the drive has that info).= -S=F8ren > Please, advise. Thanks! > > -mi > > On Wednesday 01 March 2006 11:07, Mikhail Teterin wrote: > =3D On Wednesday 01 March 2006, S=F8ren Schmidt wrote: > =3D =3D dd if=3D/dev/ad8 of=3D/dev/null bs=3D1m > =3D=20 > =3D Well, as I said, there is no obvious problems with _reading_. The a= bove=20 > =3D command reads at well over 60Mb/s: > =3D=20 > =3D 1638924288 bytes transferred in 25.374856 secs (64588516 bytes/sec= ) > =3D=20 > =3D _Writing_, however, remains pathetic: > =3D=20 > =3D dd of=3D/dev/ad8 if=3D/dev/zero bs=3D1m > =3D 631242752 bytes transferred in 91.039066 secs (6933757 bytes/sec) > =3D=20 > =3D =3D The problem is the blocksize that gets in the way of utilizing = full > =3D =3D transfer speed. > =3D=20 > =3D Did you really expect the blocksize to make an order of (decimal) m= agnitude=20 > =3D difference? :-) It made no difference at all :-( > =3D=20 > =3D Brian Candler asked: > =3D =3D Just to be clear: this is Knoppix running on the *same* machine= as you've > =3D =3D been testing FreeBSD? > =3D=20 > =3D Correct. > =3D=20 > =3D =3D Aside: why are you using cat under FreeBSD, but dd under Knoppi= x? I'd use=20 > dd > =3D =3D everywhere for consistency. > =3D=20 > =3D Cat was slightly faster in my tests on FreeBSD. I used dd under Kno= ppix for=20 > =3D dd's throughput reporting -- I'm not aware of a monitoring tool lik= e=20 > `systat'=20 > =3D under Linux. > =3D=20 > =3D Yours, > =3D=20 > =3D -mi > =3D=20 > > . > > =20