From owner-freebsd-stable@FreeBSD.ORG Tue Jul 1 13:20:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F6C9106564A for ; Tue, 1 Jul 2008 13:20:18 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.freebsd.org (Postfix) with ESMTP id 2A8398FC23 for ; Tue, 1 Jul 2008 13:20:18 +0000 (UTC) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.168) by pne-smtpout1-sn2.hy.skanova.net (7.3.129) id 483EBD680069B424; Tue, 1 Jul 2008 15:20:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message Date: Tue, 1 Jul 2008 15:20:16 +0200 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A196A@royal64.emp.zapto.org> X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 In-Reply-To: <20080701125328.GA69964@eos.sc1.parodius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MCP55 SATA data corruption in FreeBSD 7 Thread-Index: AcjbeayObNHUEQaxQraWC7RJ9n5+sQAAIRNg References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> <20080701125328.GA69964@eos.sc1.parodius.com> From: "Daniel Eriksson" To: Cc: Jeremy Chadwick Subject: RE: MCP55 SATA data corruption in FreeBSD 7 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: Tue, 01 Jul 2008 13:20:18 -0000 Jeremy Chadwick wrote: > With the same cables? Not that I want to use cables as a=20 > scapegoat, but in this case it seems applicable. With the same cables, yes. > Can you provide "atacontrol cap" output for one of the drives? # atacontrol cap ad4 Protocol Serial ATA II device model SAMSUNG HD103UJ firmware revision 1AA01112 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 1953525168 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management yes no 0/0x00 254/0xFE > I know in the case of Maxtor drives, there is a bug that exists in one > of their disk firmwares which causes silent data corruption and/or > SATA bus lockups when NCQ is used on nForce 4 chipsets. Maxtor > provides a firmware update which fixes the bug. Connecting (some of) the drives to a or a makes them work just fine. FreeBSD itself does not seem to notice any data corruption. I only noticed it because "zpool status" reported checksum errors after I had written almost 3 TB to the array. I then issued a "zpool scrub", and within a couple of minutes I already had dozens of corrupt files (so I stopped the scrub, deleted the pool and started fault-finding). --- Daniel Eriksson (http://www.toomuchdata.com/)