Hacker News Reader

Rather than a supercapacitor, the Crucial M500 uses a small array of capacitors:

All of the M500 line includes hardware AES 256-bit encryption, and Micron showed us an array of small capacitors on one of the M.2 form factor drives that supported flushing of all data to the NAND in the event of a power loss--not a super capacitor as seen in enterprise class SSDs, but there's no RAM cache to flush so it's just an extra precaution to ensure all of the data writes complete. http://www.anandtech.com/show/6614/microncrucial-announces-m...

Other features that set the M500 apart also center on optimizations that are clearly holdovers from the enterprise version of the SSD. Power hold-up is provided by a small row of capacitors that will flush all data in transit to the NAND in the event of a power loss. This feature is not standard with any other consumer SSD on the market, and in enterprise SSDs power capacitors typically command a much higher price structure. Finding power loss protection on the consumer M500 is a nice surprise, and one that users will need more often than they think. http://www.hardocp.com/article/2013/05/28/crucial_m500_480gb...

put the WAL of your database on an SSD

If you're talking about PostgreSQL, the general consensus from the mailing lists and IRC discussions seems to be that you should in fact not put your WAL on SSDs. $PGDATA/base, yes; $PGDATA/pg_xlog, no.

The amount of write churn in your WAL will burn through your SSDs wear leveling very quickly, and given that WAL is nearly perfectly sequential in access pattern, you lose (forfeit) nearly all the random IO benefit an SSD buys you.

My production master/slave pair only have SSD in them, so I'm "doing this wrong", given that advice. Our SSDs are SLC NAND, however, so their write endurance is vastly, vastly higher than the drives under consideration in both your comment, and TFA.

  What I'd like to see is:
  1) Data on which SSDs have supercap

Every SSD review I've read at Anandtech.com or StorageReview.com has mentioned the presence of a supercap on drives that have them.

When they review consumer-oriented drives without the supercap, they typically don't say "there's no supercap" but 1) there are usually physical teardown pics so you can fairly easily check for yourself 2) be pretty sure there isn't one if they don't mention it, because they always talk about it if there is one.

This doesn't help with this, of course:

  2) 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.

Would love to see reviewers test that as well. For now it seems like there's no way to know unless you're willing to do your own power-cycle torture testing.

I guess I don't understand why redundant power supplies aren't the answer in all of these cases. I'd rather nothing goes down in the event of a power failure, including the rest of the server. Even the low-end Synology RAID I use at home has two power supplies which I could (but don't bother to) plug into separate UPSes.

> 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.

Also be sure to plug each redundant power supply into a separate UPS, and avoid equipment that has redundant power supplies on a single feed. UPS failures are a bear.

And also make sure no UPS is ever loaded over ~40%, so when one of the pair fails the other can handle the full load. And always set them up in isolated pairs, with no equipment plugged into a pair member and a non-member, to prevent cascading failures.

Um, Does anyone know if Kingston SSDNow KC300 has any? Because Limestone Network are currently using them.

I have always wondered why Hosting companies aren't choosing Intel DC Series at all. As far as i know, one of the few hosting company using it are Hivelocity.

It's probably more economical for hosting companies to use lots of cheap drives in a RAID configuration. For my own desktop PC, I'd rather use a single SSD with a good reputation for reliability, together with frequent backups.

Of course, a RAID is only useful when the failure is drastic enough for the controller to notice it, which some of these power-down failures may not be.

> 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.

I'm sure there's some SMART flag that shows it. No idea which though, not one of them is properly documented.