>ZFS would help to handle some of the failure types of SSDs. I doubt that it can help in the case of a multiple disk failures due to a power failure.
It can if there's enough redundancy. If your pool is a stripe of mirrors, then you can mitigate this effect by putting each half of a mirror on separate power supplies.
Sure, but ZFS can survive intermittent drive power failure on bother halves of a mirror. As long as one good copy of a block exists, ZFS will repair the mirror by resilvering its counterpart. This is the advantage of checksumming every block on disk and using copy-on-write.
Yeah, but as opposed to data corruption, your data will throw an error when you try to read it. It's just a different failure mode. In production, SSDs will often accept a write, take a sync/flush (acknowledge they've been written to durable storage), and when reading them back, they will not return the same data that was previously written out to them.
Mirroring is also part of ZFS, but it's not ZFS magic. My preference is the Dynamo / Hadoop / layered approach in which the application is aware of multiple underlying storage devices, and is written in a way that's defensible to underlying device failure.
Yeah, but as opposed to data corruption, your data will throw an error when you try to read it.
No, the data will be repaired transparently and you won't notice a thing. Errors will be logged, of course, but you'll know that the data is intact.
My preference is the Dynamo / Hadoop / layered approach in which the application is aware of multiple underlying storage devices, and is written in a way that's defensible to underlying device failure.
And ZFS should be the underlying file system upon which these applications are built. If you don't have protection against silent data corruption at the lowest level then you aren't going to have any idea when it happens.
It can if there's enough redundancy. If your pool is a stripe of mirrors, then you can mitigate this effect by putting each half of a mirror on separate power supplies.