It's still an interesting article. It seems they've found a way of cheaply producing ammonia from hydrogen. Not sure they meant ammonia exactly, but they mention "liquid-based inorganic fuel" and later talk about how ammonia is important for fertilizer, so I'm kinda guessing that's what they're making. Ammonia can then be used to either make fertilizer, liquid fuel substitutes and a bunch of other interesting processes.

In that respect, that is correct, the increase might indeed be just noise.

This data is pretty hard to come by, I agree, so I had to make some assumptions (elaborated below). Can you cite your sources?

While it is true that some efficiency offsets might be made, your numbers simply do not add up to the graph Dunkelfalke linked. It lists lignite at 3201 TJ in 1990 and 1645 TJ in 2012. That is not "[usage] of brown coal is still nearly 20% below the 1990 level (in primary energy)", that is a 50% reduction in primary energy. All of that also happened before the year 2000 - since then, pretty much no reduction in lignite use has occurred. If powerplant efficiency were indeed rising while electrical generation remained mostly flat during the 2000-2011 period, that would imply that a rising proportion of that input lignite energy (which flatlined during that time period too) is being used for heating and other uses. However that doesn't appear to be the case either (coal use outside of electricity is falling rapidly) - this leads me to believe that there hasn't been such a dramatic increase in efficiency as to be able to confidently say that the recent increase in generation is due to an increase in powerplant efficiency. Also, how can you claim use in electrical generation is 10% below 1990, when even you said yourself just a few moments before that "no one can deduce how much more brown coal was used for that". I'd really appreciate if you could cite your sources, that would allow us to clear up the situation. If you have access to figures on lignite consumption by coal fired power plants, that would be great. Otherwise, the only reliable thing we can say is that electrical generation from lignite is at an all time high since 1990.

Maybe you should start with your own advice. The poster was referring to electrical generation here, not overall energy use. Your graph is for overall energy use (and I'm not sure about the proportions there either, they seem a bit off). You might have been clued into that by the units being petajoules (customarily used for overall energy production) not watthours (customarily used for electrical generation). Another thing that might have ticked you off is that mineral oil is a good 1/3 the energy share there. And natural gas about 1/4. In actual fact, when you look at the right graphs, in electrical generation, oil accounts for a meager 1% and gas about 11%. In relative proportions lignite has remained mostly stable since 1990, however in absolutes, 2013 (161 TWh) was indeed a record year since 1990 (171 TWh). Hard coal has also picked up in the last 5 years.

I think you misunderstood my reply. I was replying to the poster talking about iSCSI having to be implemented in ZFS. That's what I was addressing.
You talk about a different thing altogether - ZFS backing. The zvol-on-another-zpool solution should work, although performance will suck. The zvol-on-the-same-zpool solution can and will hang for obvious reasons.

I was talking about iSCSI support, not how the ZFS themselves pools are built. Yes, ZFS *does* prefer raw disk backing (due to certain management simplifications), but it does not need it. In fact, it's quite possible and people do frequently run ZFS on top of RAID arrays.

I've confirmed it by actually reading the source code. Even a quick look at the manpage will tell you the same:

Keep perspective. Are you really going to build a box like that with just one 2 GHz quad-core CPU?
I have pushed 4GB/s through a SAS SSD array on ZFS, but even so I maxed out on other stuff way before the CPU and much less checksumming ever began to be an issue (e.g. had to go through two LSI SAS 9200-8e HBAs, because one maxes out the PCI-e 2.0 x8 lanes; with two HBAs I maxed out on the two 6G SAS links to my JBOD). That the point of my post. I've yet to see a system which is constrained by the checksumming in any meaningful way.

Sun still had closed bits in the OS kernel when OpenSolaris was CDDL'd, so GPL was a non-starter because of GPL's "infectious" nature of spreading to all source that makes up a project. CDDL is more permissive in this - it simply forces you to keep the free bits that you got free, but doesn't expand to anything outside of the source files you got.

iSCSI doesn't need to be baked into ZFS, in fact, even on Illumos it isn't. It's in a completely different subsystem and will happily work with any block device as its backend storage (be it a physical drive, a ZFS zvol, a loopback block device or anything else, really).

You can thank your package maintainer for this. ZFS never ever ever upgrades the on-disk format silently. You always have to do a manual "zpool upgrade" to do it. It'll tell you when a pool's format is out of date in "zpool status", but it'll never do the upgrade by itself.

Again, this is not ZFS' fault, it's your package maintainer for auto-upgrading all your imported zpools. ZFS never does this by itself.

The overhead is barely there at all. I've measured the performance of the default fletcher4 checksum on a modest 2GHz Core 2 CPU and it comes to around 4GB/s/core. Now given that most CPUs now come with 4 or more cores, in order to get the checksum to be 10% of CPU overhead, you'd have to do be doing around 1.2GB/s of I/O. Needless to say, you're not ever going to get that even for fairly high-performance boxes.

What answer? You gave a few links to wikipedia with zero analysis to support it. You claim shit like "obviously we can get some energy back from the steam turbines too" without actually knowing and showing that doing so is feasible.
Look, it's really simple. Give your best case analysis for what you propose to do. No links to wikipedia and vague statements like "seems your main technical objection is being worked out with a 780 KW beam for spallation". Tell me exactly how you propose this to be done and how that adds up quantitatively. How much power, in what accelerators, how much would such a system cost and how would you propose we construct it. No more evading. Talk to the point.

Because you're being so disingenuous. Any time I show you how wrong you are using very basic mathematics, you just change the subject, or make a new equally outrageously wrong claim.
Anyhow, now that you're finally making claims which are at least vaguely quantitative and testable, we're at least getting somewhere.

First off, I hope you meant beam current, not luminosity (since that's a property of accelerators with detectors), since that's the property that actually tells you the number of particles in the beam and therefore how many nuclei you can affect. Second, the rate at which you do it doesn't change the total energy investment needed, it'll still cost about $20bn/ton. Oh and how much such a large number of facilities would cost to build and operate is a whole other matter. Oh and the transmutation products might still very well produce a significant amount of decay heat, so you'll have averted exactly zero risks of meltdown (though this depends on the details of your proposal).
But go ahead, present your detailed numerical analysis. Perhaps you have some amazing physical insight that makes this all wonderfully efficient, safe and sensible.

Shut up it is then.

The MEGAPIE accelerator you linked gives tops ~1mA of current and substituting tritium for protons lowers that by about a factor 3. I'll spare you the numbers, but in effect, to consume 1 ton of long-lived fission products this way would take on the order of 50000 years to the tune of some $20 billion per ton just for the power needed to run the system. If you think this is even remotely practical, you're an idiot. And this is the absolute best you can do, ignoring all practical issues of handling large quantities of radioactive tritium and fission products, chemical SNF separation, Tritium's limited half-life (so the need to regenerate it), cooling requirements, physical arrangement, etc.
The reason MEGAPIE was built and your crazy fission-product incinerator wasn't is because the guys at CERN are actual scientists and you're just an Internet armchair expert.

WHAT THE FUCK. I have no understanding? When it is you who can't show the first thing about anything quantitatively and just deflects from the topic? You're like a textbook example of the Dunning-Kruger effect. You're so overconfident in your statements, yet when pressed, can't support any of them with hard data. All you can do is google stuff you vaguely half understand, ignoring all practical problems with it, forgo any and all mathematical analysis and declare victory.
I'm done. If you post your mathematical analysis of such an incinerator system, I'll respond. Anything else, I'll ignore.