Date: Mon, 9 Nov 2015 13:25:53 -0600 (CST) From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> To: Tim Gustafson <tjg@ucsc.edu> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS RAID 0+1 Throwing Checksum Errors Message-ID: <alpine.GSO.2.01.1511091320580.20442@freddy.simplesystems.org> In-Reply-To: <CAPyBAS7oYvp6vvzetcGmrXy0_Qn0fXBN_d510w41CguDZCzMxw@mail.gmail.com> References: <CAPyBAS7oYvp6vvzetcGmrXy0_Qn0fXBN_d510w41CguDZCzMxw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Nov 2015, Tim Gustafson wrote: > > I'm wondering if the problem is that the scrub is calculating the > checksum for the data on gpt/zfs0, and while that's happening, some > data is updated by Apache or MySQL, and then checksum for the data on > gpt/zfs1 is calculated, which now doesn't match, and therefore the > scrub is reporting an error. Is that possible? This is not possible. ZFS uses Copy On Write (COW) such that existing data blocks and metadata are not overwritten. Data is always written to unused free space. The writes are done as part of a transaction group, and scrub will not see new data until the transaction group is completed. > If that's not it, could this be a bug? Or should I be worried about > my SSDs? What additional data would be helpful for me to share to > diagnose this? It could be the SSDs, the controller, cables, or power supply. The problem might occur when the data is written, or when it is read back. If this is occuring on all of the SSDs then look for some shared component which might be causing the problem. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.2.01.1511091320580.20442>