It appears he has removed his article. I click on it and it has no body.
Just reading the comments made, he seems to have stirred the hornet's nest with some comments about ECC. Well deserved too IMO and the person that quoted him and responded is totally correct.
It also appears that he argued back at the person with ECC, with comments that are laughable as he clearly has NO understand of what ZFS does or how it works...
>> "No. It doesn't *only* apply. It's strongly recommended as business data = money. However, my family photos from years gone by are priceless to me and I want to take precautions to keep them safe forever. Yes, I back them up, but a flipped bit won't show up until years down the line when my grandkids want to look at the photos."
I do not think storing family photos will be affected by the use of ECC RAM, for two reasons. First, a few bit flips are unlikely to be noticed while viewing the photos. Your photos are likely to be affected by bitrot less than a physical phtoto would fade over time. Second, unless you are looking at (and editing) the photos on a regular basis, the photos will spend almost zero time in RAM. Photos will almost certainly spend 99.9% of their lives on a hard drive or other storage media. Having ECC RAM would only affect your photos if you were opening them, editing the photo and then saving the result on a regular basis, which seems unlikely. ECC RAM will not protect you against bitrot on the storage media.
Financially you (and the photos) would be much better off investing in an extra external hard drive or optical media so you can store multiple backups of your photos. ECC may have uses outside the enterprise, but protecting family photos isn't likely to be one of them.
Yeah, he has ZERO concept of ZFS if he's giving advice like "better off investing in an extra exteranl hard drive". WRONG. The whole point of ZFS is so you can prove, for certainty, that all the bits are actually there. You cannot do that, even if you have multiple copies, unless you intend to cross-compare from two sources (and you'd be laughed at if you went to that kind of extent to validate you had 1 copy that was "safe").
Family photos isn't likely to be one of them!? Has he even see the FreeBSD, ZFS on Linux, or FreeNAS community!? We're *all* part of that group. Has he even looked at the users we've seen around here that lost their entire pools because of bad RAM?
And a few bitflips aren't likely to be noticed!? Really! There's a website somewhere that took some pictures and changed a single bit. The end result was a broken image that wasn't worth saving. So yeah.. a single flipped bit can be a big deal for you if your pictures are valuable. (In fact, the fact that some of my picture have been corrupted over the last 10+ years is *why*, after I read about ZFS, I went all-in and went to FreeNAS.)
@45: >> "Typically, you'd schedule scrubs once or twice a month. During this time, the file system checks your disk for any errors and automatically corrects them if corruptions are found. ZFS, however, cannot detect bit errors in RAM and so, this could result in the file system actually "correcting" your file that is perfectly fine, which inadvertently corrupts it instead."
You are half right. When ZFS performs a scrub it does check the data on disk against a checksum to make sure the data's integrity has not been comprimised. However, ZFS only attempts to correct the bad checksum if it is used in a RAID or mirrored disk scenario. What this means is if the checksum of one copy of the file is bad and another copy of the file is good, then the bad copy is replaced with the good copy.
For a ZFS scrub to over-write a file, it needs to have another good copy of the data to use. The corrupted file is overwritten by a known good copy. Even if ZFS mistakenly thinks a good file is really corrupted, it will only replace that file with a verified good copy of the data. This is discussed in the zpool manual page under the "scrub" sub topic.
Laughable. It won't fix a file without another good copy!? No, scrubs work at the BLOCK level. If a BLOCK is corrupted, it's replaced with data from either a mirror or parity data (that is verified good). There is no differentiation between a block of file data and a block of metadata. It is all checksummed and all replaced with either parity data or the mirror, after validating that the alternate source is good.
Clearly he does not understand the tech he is writing about.
"Armchair ZFS expert" is what I'd call him. Kind of like an Armchair lawyer, but just as clueless.
