Analysis of SSD Reliability during power outages
What I find rather annoying is that manufacturers/marketers rarely state whether or not an SSD has a supercapacitor or not. Here have been my finding:- OCZ Vertex 4 SSD does (but this is not advertised)- OCZ Vertex 3 does not, Vertex 3 Pro does- Ditto for Vertex 2 / Vertex 2 Pro- OCZ Deneva(2) R does, other OCZ Deneva/Deneva 2 do not -- and in the case of Deneva 2 R this is advertized- Intel 320 does (but is only sata II), but this is not advertised at all- Intel 520/530 does not- Intel 330/335: unclear- Intel S3700/S3500: does and this is advertisedBackground: I was looking for an SSD to use for a ZFS intent log ("ZIL" -- ZFS's write ahead log) -- my requirements were a sandforce controller (or equivalent) and toggle NAND (so that I could use the same disk for both ZFS cache and the ZIL), and a supercap. This was surprisingly hard to find.What I'd like to see is:1) Data on which SSDs have supercap2) Data on which SSDs actually honour cache flush request (then a UPS + forcing a cache flush request upon power failure + redundant power supplies/multiple replicas in a distributed system) would suffice.3) Best yet: have an API for for check whether or not an SSD has a supercap, whether or not the supercap still holds charge, and policy for honouring cache flush requests. Let the OS decide based on a policy I set.If you are a consumer, the practical recommendation is not very different from the practical recommendation I'd give to anyone using spinning disks: RAID1/1+0/RAIDZ(-2) (with SSDs coming from different patches so that they do not wear out at the same time), UPS (for power outages),  backups (against yourself and against power supply failures).For production: obviously use a UPS, put the WAL of your database on an SSD with a supercap, make sure that your database fsync()'s the WAL at a reasonable interval (on every transaction is probably unreasonable, but so is once an hour), and use a distributed system that replicates the WAL. If using a distributed system with (semi-)synchronous WAL replication is not an option and losing incremental data is not acceptable, use redundant power supplies.