MCP55 SATA data corruption in FreeBSD 7
Daniel Eriksson
daniel_k_eriksson at telia.com
Tue Jul 1 13:20:18 UTC 2008
Jeremy Chadwick wrote:
> With the same cables? Not that I want to use cables as a
> 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/)
More information about the freebsd-stable
mailing list