Neither is ext3. Nor ext4. Nor btrfs. And thus, none of these will work on dual-Primary DRBD. Nor active-active shared storage. Nor any synchronously replicated active-active SAN. And we’re telling you very clearly.
So if you choose to ignore all warnings and put ReiserFS on dual-Primary DRBD, and mount it from two nodes, you’ve just signed up for wrecking your data. And when that happens, don’t come whining. And don’t blame DRBD or any other of the technologies you may be choosing to employ while ignoring the documentation.
Florian's blog 
Quite obvious of course.
Now when I come to think of it, I’m wondering if it would make a difference if (at least) one node would be mounted read-only?
I’ve answered that one before, too.
Ouch, of course. “A file system is typically ignorant of what sort of block device lives underneath it.” I should have realized that.
I’m not entirely agree with you.
I mean that ReiserFS (or ext3, 4, …) is not a cluster fs… WHEN DRBD IS USED.
But, drbd is not the only solution for a cluster.
For example, glusterfs can be used with reiserFS or ext3 and can use the features of the FS.
Thank you for your blog
OK, I should clarify. In the HA community, “cluster file system” is a clearly defined term that means “file system which will allow concurrent access to a single data image from multiple cluster nodes in a coordinated fashion,” which encompasses the use of a distributed lock manager, some form of quorum arbitration, and fencing. That’s the sense in which I use “cluster file system”.
And yes of course, when you use a distributed file system like GlusterFS which is layered on top of a locally running file system, then that local file system is typically not a cluster file system.
But, at any rate, running ReiserFS off of dual-Primary DRBD, or shared storage, or a replicated SAN, and mounting that device from multiple nodes concurrently — that’s a really really bad idea.
But, Florian, they used the word “proactive” in that highscalability.com post. How can it be wrong if it’s proactive? Anyone who’s proactive surely can’t be the cause of their own problems.
There were a couple of WTFs in that post. Why are they running a MySQL slave on each Webserver?
If it’s to eliminate latency – they’re doing something wrong. If it’s because of capacity problems, it would have been architecturally simpler (and engineering time) to buy a bigger database server…
… that is assuming they needed a bigger server. There is no mention of working set/memory fit, if queries have actually been optimized, etc. We are not even told if the database servers have anything better than 7200RPM disks.