I'd love for you to be right, but you haven't added any information to the discussion so it is hard to believe you.

and yet, Germany is the large per capita CO2 emitter in Europe at 9.7. In addition, with more coal plants coming on-line, again, Germany will jump up again.

No, because the corruption will be caught. I - and many others - have had controller failures and bad hard drives cause corruption on the drives, but this corruption was caught during the scrub. If the data is bad in-memory and then hashed and written to disk in that condition, the corruption will be silent.

ECC RAM will only correct 1 bad bit, but the system is supposed to halt on 2 bad bits. A halt is better than operating in an unknown state, IMHO.

Even if you aren't worried about the specific scenario where the whole pool goes down, taking all the trouble to run a filesystem with parity seems silly if you can't trust the error detection/correction to actually work. And since you are writing a hash as well as a file, you are doubling the opportunities to corrupt any particular file vs a regular file system.

I'd suggest some further reading.

Not something I would attempt. Personally, I accept this limitation and always add drives in pairs. Upgrading capacity then becomes a 2-drive cost instead of a number_of_disks_in_raid cost.

It's not THAT bad. You do this:
1. Put new disk in usb cradle.
2. Run 'zpool replace', swapping new disk for old disk.
3. Take the new disk and physically replace the old disk.
4. Repeat 1-3 for each new disk until you have the whole array running at the new capacity.
5. If autoexpand is not enabled, run the 'zfs online' command with the '-e' flag to use the new capacity.

I've only used FreeBSD, not Linux - but I presume this would work so long as you are giving ZFS the whole disk. ZFS does not care which interface disks are attached to... you can take them all out and shuffle them around and it will map them correctly.

I think the majority of the scientific publishing culture and industry is bad for science. That said, this is not a fair criticism. It's entirely reasonable to tell someone you expect to see more data in order to publish and to start a conversation among the editor, reviewers and PI as to what is necessary to prove a point. Research is not a perfect process and does not progress in an orderly, predictable manner. There are going to be typos and blind spots in any paper.

In this case, obviously Nature should not have published in the end. We can't know how that decision was reached unless we see all the correspondence between the editor, reviewers and PI. It would be much more useful to the scientific community to see how the PI managed to convince the reviewers to allow publication, rather than to debate what is really a standard rejection response.

I've been a member of the Church of Parity ever since I discovered that some of my dutifully backed-up family photos had not only gotten corrupted, but the backup dutifully copied the corruption as well. Ever since, I use backup tools which do a parity check (e.g. Unison) and I try to store important things on ZFS if I can.

In my case I was lucky and I had an older backup without the corruption. But lesson learned... Also, have more than one backup :)

Yes, ZFS is not a Drobo. You need to plan out your disk usage from the beginning, because you are kind of stuck with it.

For instance, if you have 5 disks and they are all the same size and you want 2 disk redundancy, it is almost a no-brainer to setup a raidz2. The downside is that if you ever want to make the vdev larger by replacing disks, you need to replace all 5 disks to the new larger size... a vdev is limited by the smallest disk. You can mitigate this by putting the same 5 disks into a pair of mirrors plus a hot spare. You will lose some initial capacity, but then later on you can add capacity by swapping out just two disks or by adding another pair to the pool.

And once you've added a vdev to the pool, you can never remove it... that's probably the biggest irritation for me personally. Even that isn't such a big deal, since it is so easy to clone the whole pool to another one.

If you decide to chance it, make sure you don't use the "scrub" functionality on ZFS. Scrub can cause memory errors to eat your pool like a cancer.

Or, just use ECC :)

There is "free as in beer" (usually both GPL and BSD). There is "free as in freedom" (BSD). And then there is "free as in free-range chickens" (GPL).

I would add to you "cons" list that it requires* ECC RAM, though you should probably be using that anyway.

* It's not technically a requirement, but you'll probably be sorry if you don't use it.

No, Europe's really is about economics, but China and Russia join america's military focus on this.

Zero chance. America helped China before and what was found is that solutions were put into military before civilians. Basically, China values military use over civilian use of space.

where life us going to get interesting is when american private space lands on the moon in 2020-2022 and starts a base.

"And it came to pass that AC learned how to reverse the direction of entropy.
But there was now no man to whom AC might give the answer of the last question. No matter. The answer -- by demonstration -- would take care of that, too.
For another timeless interval, AC thought how best to do this. Carefully, AC organized the program.
The consciousness of AC encompassed all of what had once been a Universe and brooded over what was now Chaos. Step by step, it must be done.
And AC said, "LET THERE BE LITHIUM!"

And there was lithium---- "