I tend to agree.  RAID 1 is fine for your desktop where you don&#x27;t want to waste time restoring your backup when a drive inevitably dies.  When the kernel gets confused and says both drives are corrupted simultaneously, it&#x27;s easy to manually repair with dd.  (See which block has unrecoverable errors and copy that one over from your other drive.  Repaired.  Not sure why the kernel can&#x27;t do this automatically.  The data is gone, you can&#x27;t make it worse.)<p>For datacenter applications, having everything on one machine behind a filesystem abstraction seems like unnecessary complexity, not to mention a single point of failure and a waste of resources.  I&#x27;d much rather handle things on the application level; if I want three copies of my data around, write it to three different machines with disks.  When a copy seems unavailable, make an extra to keep the redundancy level the same across disk failures.  If I want some redundancy encoding, just store that instead of the raw file.  Now there is no complicated recovery when your disk fails.  The system is always in a recovered state because disk failures are expected and uneventful.<p>That said, there is a bit of complexity in implementing this, and even more complexity when you want all the pleasantries of a UNIX filesystem (permissions, quota, etc.).  I know of only one working implementation of this technique, and it&#x27;s not open source.  And, of course, if you&#x27;re going to use existing software rather than writing your own, you&#x27;re going to need a UNIX filesystem for it to use, not some clever chunk storage manager you wrote.  So btrfs and zfs persist.