Date: Fri, 29 Apr 2016 08:31:22 -0500 (CDT) From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us> To: "Michael B. Eichorn" <ike@michaeleichorn.com> Cc: freebsd-fs@freebsd.org Subject: Re: How to speed up slow zpool scrub? Message-ID: <alpine.GSO.2.20.1604290821210.23612@freddy.simplesystems.org> In-Reply-To: <1461736217.1121.17.camel@michaeleichorn.com> References: <381846248.2672053.1461695277122.JavaMail.yahoo.ref@mail.yahoo.com> <381846248.2672053.1461695277122.JavaMail.yahoo@mail.yahoo.com> <1461736217.1121.17.camel@michaeleichorn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 27 Apr 2016, Michael B. Eichorn wrote: > > It does not *need* to be ECC ram, ECC is just *highly recommended*. As > one of the key features of zfs is bitrot prevention, it makes sense to > protect against bitrot everywhere. Zfs (and thus freenas) is just fine > with non-ecc ram. Just, like for any filesystem if the bit is flipped > in ram it will be recorded as such on disk. This is not necessarily the case. Zfs does not offer additional protections for data in RAM. It assumes that data in RAM is protected in other ways. The on-disk checksum only verifies that the data was not modified since it was checksummed, but it may already be corrupt. The risk factor is pretty high if RAM becomes corrupted since zfs uses so much RAM. It is possible to lose data and even the whole pool due to memory corruption. There are well known cases where users encountered continual/periodic pool corruptions due to flaky RAM. 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.20.1604290821210.23612>