Re: ECC support
"alex.burlyga.ietf alex.burlyga.ietf" <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.hardware,gmane.os.freebsd.devel.hackers |
|---|---|
| Message-ID | <CA+JhTNTrs8uebH4a4Xb3CK4=Br1cYS=NixZD_mBbN07ddww4HQ@mail.gmail.com> |
On Tue, Sep 15, 2015 at 3:52 PM, Igor Mozolevsky <[email protected]> wrote: > On 15 September 2015 at 23:34, Jim Thompson <[email protected]> wrote: > > <snip> > > >> I think you’ll find that the default for ‘scrub’ is off on most (perhaps >> all) boards. There are reasons, and these relate directly to >> “significantly diminish system performance”, (above), as well as the >> greatly increased RAM sizes in use today. >> > > Perhaps I missed something- what point is it that you're trying to make? I > was saying that scrubbing aims to remove errors at the source (cf. "on > demand") and prevent multi-bit errors that become detectable but > irrecoverable, or worse, undetectable. Get hit by a few of the latter two > at "interesting" points and you'd wish that scrubbing were on! > > And seriously, ECC scrubbing is slow but ZFS (or even hardware RAID) > scrubbing is lightning fast??! C'mon are we going for data integrity or > speed here?! If I remember correctly enabling Patrol Scrub guaranties that each address gets hit once per 24 hours. So on 128GB system you are generating maybe 1-2MiB/s of reads. I'd say it's a good trade-off if you bothered to put ECC memory in. > > ’Scrub' was popular about a decade ago, when DDR2 RAM was around $100/GB. >> DDR3-1600 is about $6/GB today. >> > > Yup- with a much higher density of smaller memory bits! ;-) > > -- > Igor M. > _______________________________________________ > [email protected] mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[email protected]" _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "[email protected]"