Date: Tue, 1 Jul 2008 15:20:16 +0200 From: "Daniel Eriksson" <daniel_k_eriksson@telia.com> To: <freebsd-stable@freebsd.org> Cc: Jeremy Chadwick <koitsu@FreeBSD.org> Subject: RE: MCP55 SATA data corruption in FreeBSD 7 Message-ID: <4F9C9299A10AE74E89EA580D14AA10A61A196A@royal64.emp.zapto.org> In-Reply-To: <20080701125328.GA69964@eos.sc1.parodius.com> References: <4F9C9299A10AE74E89EA580D14AA10A61A1968@royal64.emp.zapto.org> <20080701125328.GA69964@eos.sc1.parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <JMicron JMB363 SATA300 controller> or a <Promise PDC20318 SATA150 controller> 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/)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F9C9299A10AE74E89EA580D14AA10A61A196A>