Page 1 of 1

ZFS trumps BER/bit rot - or not?

Posted: 31 Jul 2013 05:38
by Ecnerwal
In the perfect world of unlimited budgets, naturally I'd load up the finest hard drives money can buy. And I don't particularly want to go with the cheapest hard drives money can buy - but I'm trying to figure out where to point the funds I can actually scrape together. Ordered up a (used) 64 bit box with ECC memory. 4 drive slots, not as good as 5, but that's what it has unless I graft one on the outside (if there's a port to support it on the motherboard.) Many folks seem to be happily using WD Reds, which provide an "interesting" BER of <10 in 10**15 - which smells to me a lot like 1 in 10**14 (with honest rounding) plus a layer of smarm applied to get 10**15 (might well be 9 in 10**15) in there, when not too far off [edit - bad memory of prices they are much more affordable...] in price there are Hitachi drives with 1 in 10**15. The 1 in 10**16 drives are way out of my league, especially when buying 3, 4 or 5 at a whack in multi-terabyte sizes. School, not home use - tight budget but trying to hold to "real" standards as much as possible.

Does ZFS effectively make the BER much less of a concern - and as such, much less of a thing to point money at if using ZFS?

Yes. I know, point my money at backups - As presently envisioned, the N4F is (going to be) one of my backups (an online one, physically separated and connected by network.) I have others offline in a bank vault, and others too physically close (in same building) to the servers they are backing up for comfort - thus the N4F...in a different building.

Re: ZFS trumps BER/bit rot - or not?

Posted: 04 Aug 2013 20:33
by substr
Bit rot, yes. BER, no.

If you're using mirrors, raidz, or copies=2, then bit rot would be corrected.(It will be detected in all cases, unless you've turned checksums off.)

BER problems can be somewhat offset by doing a scrub on some kind of schedule. That allows some problems to be discovered and corrected before a drive failure.

The problem with BER is that it is also describing how likely a spontaneous read error is over a given amount of data read. During a resilver, such an error is a distinct possibility with 1-10^14 BER drives and big pools.

If you get unlucky and run into a BER while the raidz is trying to resilver your replacement of the failed drive, you will get data loss for the block that is affected. (There is also a possibility that the drive that experiences the BER will be considered failed, so while you will lose at least one block, you could lose the whole pool depending on the reaction to the BER) Since you can't do anything about these kind of spontaneous BER errors, you have two choices: buy the more expensive drives with better BER, or use something like raidz2, which can withstand the second failure without losing data.

If the ZFS pool is just one of many backups, you could use raidz and just ignore the BER question. However, if that is really how you feel, skip raidz, and operate with no redundancy: Then you'll really know you aren't worried about losing the data. :)

There is no need to point money at BER unless your ZFS pool is concerned with very high uptime. If your scrubs start turning up errors, increase the frequency of scrubs, or replace whatever is the source of the errors.