On Sun, Dec 9, 2012 at 1:27 PM, Jim Klimov <jimkli...@cos.ru> wrote:
> In two of three cases, some of the sectors (in the range which
> mismatches the parity data) are not only clearly invalid, like
> being filled with long stretches of zeroes with other sectors
> being uniformly-looking binary data (results of compression).
> Moreover, several of these sectors (4096-bytes long at same
> offsets on different drives which are data components of the
> same block) are literally identical, which is apparently some
> error upon write (perhaps, some noise was interpreted by several
> disks at once like a command for them to write at that location).
> The corrupted area looks like a series of "0xFC 0x42" bytes about
> half a kilobyte long, followed by zero bytes to the end of sector.
> Start of this area is not aligned to a multiple of 512 bytes.
Just a guess, but that might be how the sectors were when the drive came
from the manufacturer, rather than filled with zeros (a test pattern while
checking for bad sectors). As for why some other sectors did show zeros in
your other results, perhaps those sectors got reallocated from the reserved
sectors after whatever caused your problems, which may not have been
written to during the manufacturer test.
These disks being of an identical model and firmware, I am ready
> to believe that they might misinterpret same interference in the
> same way. However, I was under the impression that SATA involved
> CRCs on commands and data in the protocol - to counter the noise?..
There is 8b/10b encoding, though I am not entirely sure how well this
counters noise (it is intended to DC-balance the signal and reduce run
length). I don't know if there is further integrity checking, though one
would hope that noise wouldn't decode as a sensible ATA command.
Question: does such conclusion sound like a potentially possible
> explanation for my data corruptions (on disks which passed dozens
> of scrubs successfully before developing these problems nearly at
> once in about ten locations)?
Potentially? I suppose, but I would bet on something else (controller went
zfs-discuss mailing list