How to speed up slow zpool scrub?

[Karl Denninger]

On 4/29/2016 08:31, Bob Friesenhahn wrote:
> 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

To amplify what Bob said using ZFS on a system without ECC RAM is just
begging to lose the entire pool at some point due to a random bit-error
in system memory and the fact that it happened may be completely
concealed from you for quite a while until at a random later point in
time you discover the pool is hopelessly corrupt.

ZFS makes the *assumption*, fair or not, that everything in its
RAM-based caches is correct.  If that assumption is violated you will
eventually be a very sad Panda.  Use ECC memory or don't use ZFS.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20160429/4184b339/attachment.bin>