...the one-eyed man is King.

Or maybe that should be blindfolded.

OpenVZ is not the same as the rest. It takes the host O/S and creates skinny containers from it that appear as individual systems; but that's not the same as "virtualization" in this context. You can't run an alternate O/S using OpenVZ.

What you actually said was:

Has anybody here on Slashdot had any experience with one or more of these clustered file systems?

.. and OCFS2 was not on that list. From the rest of your reply it seemed to me that you were confused about the capabilities of OCFS2. My apologies.

The rest of my comments, WRT mdadm etc, we're not related to clustering, or sharing direct attached raid devices between systems - because as others have also said, I don't think that a cluster best suits your requirements. Unless of cause you just want to do it for the fun of it, in which case go for it.

Or alternatively you back everything off to tape (rotating sets) and store them in a fireproof safe.

How is this an answer to your question? You identified 3 cluster filesystem types that protect against hardware loss by distributing the data over a cluster of systems - but OCFS2 isn't like that. It's a filesystem that's designed to provide concurrent shared access to a filesystem by a cluster of servers, which in combination with a HA framework can provide a platform that applications can use to protect against node failure, not disk failure. With OCFS2 you still have to make the storage highly available with a RAID solution plus manage concurrent connectivity via a SAN, iSCSI, etc. So unfortunately this is not an answer to your question at all. The filesystem types you've identified would do what you want, but they're also expensive for a home solution because you have to throw more computers at the problem to increase redundancy and performance.

Have you considered using software RAID (mdadm) on Linux instead of a hardware RAID controller? It has a useful feature that allows you to grow existing raid volumes by adding more disks. Maybe combine that with a small UPS to allow your system to shutdown gracefully in the event of a power failure. Alternatively, if you want to stick with a hardware solution have you taken a look at Drobo? I have no personal experience with Drobo, but from what I've read their proprietary RAID solution allows you to grow your array by just popping new disks in or increase capacity by replacing existing disks with larger ones on the fly. They have a couple of different models that can scale to 16TB. Best of luck with your search.

Not one x86_64 laptop is certified on that list.

Last update for those unixutils tools was 8 years ago. I hope there are no nasty security bugs lurking in there or you've just compromised your entire estate.

Last time I checked my eyeballs didn't work very well with objects. They handle text perfectly well though. Seriously, you're missing the point. The command line is for running commands and eyeballing text output. Bash functions perfectly for this. It's also perfect for writing small quick scripts that do simple tasks. If I need to do something ore complicated that requires an OO approach, then I have python or ruby to play with. Use the right tool for the job.

That's because creationist Christianity (usually evangelical) is a cult. It's not recognised as such by most because it's become so main stream; but any religious sect that preaches absolutes (e.g. the bible is inerrant) and is blind to any other way of thinking is a cult.

I'm not familiar with how Ubuntu package and push their software. Do you get everything inc the kitchen sink with each crank of the wheel whether you want it or not? Red Hat, in between major/minor releases bundle up new RPMs into errata. An errata may contain one or more RPM packages that are tested/required to be installed together, and they're delineated into three types, prefixed with:

RHBA - Red Hat Bugfix Advisory
RHSA - Red Hat Security Advisory
RHEA - Red Hat Enhancement Advisory

In our production environment, we avoid anything that's an enhancement (too risky) and consider each bugfix and security errata to see if it's application to our builds, and whether we want to install them or not, and whether the fixes would warrant a new QA effort (time consuming and costly). We're not forced to, nor are we forced to take each point release in turn if we don't want either. That's the way it should be done.