Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Apr 2016 16:28:18 +0200
From:      "Ronald Klop" <ronald-lists@klop.ws>
To:        freebsd-fs@freebsd.org, "Karl Denninger" <karl@denninger.net>
Subject:   Re: How to speed up slow zpool scrub?
Message-ID:  <op.ygoqhgabkndu52@ronaldradial.radialsg.local>
In-Reply-To: <08d59afe-c835-fa8d-0e52-78afcb1cc030@denninger.net>
References:  <381846248.2672053.1461695277122.JavaMail.yahoo.ref@mail.yahoo.com> <381846248.2672053.1461695277122.JavaMail.yahoo@mail.yahoo.com> <1461736217.1121.17.camel@michaeleichorn.com> <alpine.GSO.2.20.1604290821210.23612@freddy.simplesystems.org> <08d59afe-c835-fa8d-0e52-78afcb1cc030@denninger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Apr 2016 15:47:22 +0200, Karl Denninger <karl@denninger.net>  
wrote:

> 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.
>

Just like UFS makes an assumption about correct memory and correct disks?

ECC helps ZFS as much as ECC helps UFS.
And without ECC ZFS provides more failsafes than UFS. But nothing is  
perfect.
You guys make it sound like ZFS has no added benefits if you don't use  
ECC, which is not true.

UFS < ZFS < ZFS+ECC
And UFS+ECC is somewhere in between probably.
As long as people understand the risks/benefits things are ok.

Ronald.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.ygoqhgabkndu52>