This is a discussion on Re: Analysis of disk file block with ZFS checksum error - FreeBSD ; Eric Anderson wrote: > I'm starting to think there is a timing issue or some such problem with > ZFS, since I can use the same drives in a gmirror with UFS, and never > have any data problems (md5 ...
Eric Anderson wrote:
> I'm starting to think there is a timing issue or some such problem with
> ZFS, since I can use the same drives in a gmirror with UFS, and never
> have any data problems (md5 checksums confirm it over-and-over). I
> highly doubt that everyone is seeing similar issues and it just is
> because ZFS is so intense. I've had plenty of systems under severe disk
> load that have never exhibited corrupt files because of something like
I also wondered this - i.e. if ZFS was triggering a certain timing
behavior that revealed the problem. Still, if this is the case, it
seems to me that the problem lies in the ATA subsystem, since it should
prevent a higher-level things like ZFS to be able to create bad timings
(or am I not thinking of this correctly?).
Also, I think there were some reports of problems with DMA/ATA when
*not* using ZFS.
> I wish we could get our hands on this issue.. Seems like some common
> threads are ATA/SATA disks. Is your setup running 32bit or 64bit
> FreeBSD? (if you already mentioned it, I'm sorry, I missed it)
This was on 32bit FreeBSD with PATA. I am the one who had no SMART
issues and no DMA errors reported under Linux. Changing the cable may
have "fixed" it, since I did not see errors in some further testing, but
even if so, my theory is that there is some edge case (timing?) that the
FreeBSD ATA drivers were sensitive to, and perhaps my change of cables
pushed the problem to the other side of the threshold. Since I never
saw errors under Linux (and I've been using that cable for a couple of
years), I do not necessarily think the cable was actually "defective".
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"