Do these drives feature power-loss capacitors? I'm still wondering why most manufacturers think it's okay to offer SSDs that lose data on power loss (!!)
> Right now, there is only one reliable SSD manufacturer: Intel.
Indeed I find it very hard to figure out for other vendors whether they have power loss protection or not.
Intel makes this easy to check: Each drive has a YES/NO for "Enhanced Power Loss Data Protection" which is described as
> ... prepares the SSD for unexpected system power loss by minimizing data in transition in temporary buffers, and uses on-board power-loss protection capacitance to provide enough energy for the SSD firmware to move data from the transfer buffer and other temporary buffers to the NAND, thus protecting system and user data.
They also have a list showing all Intel SSDs that have this feature:
https://ark.intel.com/Search/FeatureFilter?productType=solid...
Would be nice if other vendors had that too.
Even in the enterprise market, M2 form factor SSDs rarely have these capacitors, because they don't really help. They are more common on PCIE-card devices.
The on-disk/flash format that these drives use has a journaling system much like modern filesystems do, so they know if blocks were not fully written. This feature alone almost completely negates any need for
I have committed patches and code to UBIFS and I am very familiar with how modern flash filesystems work at the hardware level. Backup caps are just not really needed.
PS: The double exclamation point and whiney-blamey statement really added to your immature hyperbolicity.
The capacitors needs to be reliable, small form factor and hold enough charge to keep the controller, DRAM and NAND powered for a minimum of 15-30ms. 10 years ago what was available was not so great but now the options are much better.
I jumped ship from SATAs to M.2 a month ago with a new computer and to quickly sum up the situation with Samsung 960 Pro from own experience and hundred page long threads on official product forum:
- last published firmware on website is 2 (don't know the long number now, writing from phone)
- a version 3 was released, system freezing started occurring in some cases and some people even ended up with bricked drives (in relation to eDrive IIRC)
- bricked drives could be reportedly used again after PSID revert, but Samsung consistently refuses to release the tool (other manufacturers do and the tool is also useful for recovering drive with lost OPAL password)
- firmware 4 reportedly exists, which can be obtained through Magician (Samsung's tool for SSD) and should solve problems from version 3. Conflicting reports on performance.
The craziest stuff is that:
- Magician will now tell you there is a new firmware for your drive, but it won't tell you with which version is it going to "enrich" your shiny new drive. Will I get 3? Or 4? Especially when only 2 is posted on the Samsung's page!
- firmware changelogs are kept secred, just install this for no reason
- no downgrades are possible
Worse than X25-M password bug. You have to be scavenging official forums for information that should be posted with the firmware and be cursing at/begging moderators to reveal some more. Ah and reportedly there is some mysterious incompatibility with major BIOS vendors in regard to eDrive. No, they won't tell what the bug is, nor on what boards.
Also, custom OPAL PBAs (image flashed to special unlocked area on disk for booting with disk locked down) don't boot in current desktop boards. Might be non-Samsung issue, maybe the one mentioned above.
How does this stuff work together at all?
Have a look at this wonderful marketing page for a Gigabyte Z370 motherboard:
https://www.gigabyte.com/us/Motherboard/Z370-AORUS-Gaming-7-...
It's the most over-the-top glorious thing I've ever seen. Make sure you expand a couple of the sections.
Or maybe it is, but I have no idea?
The diode is going to drop 0.6V, leaving you with only 4.4 V max for the drive. Then the capacitor is going to immediately start dropping in voltage as soon as you start pulling the stored energy out of it.
So, in practice, to do a quality job of this it will probably need a DC-DC converter. These aren't necessarily expensive, but definitely more complicated than the old diode trick.
They also frequently cache data which can be difficult (slow) to write, for example a single modified 4kb page which is part of a large unmodified area. Completing that write would involve reading the original data, erasing the entire erase-block, and rewriting the new data.
SSD's with built in power loss prevention typically reserve an area on the SSD which is pre-erased ready to dump the contents of the cache into. Then on powerup, they reload the cache and properly flush the data to the actual place it's supposed to be.
[1]https://www.maximintegrated.com/en/products/analog/amplifier...
Most motherboards don't report that to the OS though, instead they simply reset all the hardware.
To be fair, it's probably preferable to reset stuff than to operate when the power supply isn't healthy, since that will lead to a lot of weird undefined behaviour.
No. Data loss protection needs to be built into the software itself, fixing that on the SSD level doesn't make a lot of sense. If anything, you install a UPS, and then of course you don't need to pay extra for SSD capacitors because the whole system keeps running through power loss and shuts down gracefully.
When the OS flushes stuff to the device, it is done such that metadata writes reach the disk in an order that ensures a recoverable filesystem image on power failure. If the device does not preserve that ordering all bets are off. The mapping that goes on inside a SSD is of sufficient complexity that it's much easier to simply guarantee the device has enough independent power to ensure all acknowledged writes are persisted after acknowledgement, and that means capacitors, or best case, data (e.g. committed, acked DB transactions) that magically disappear during a power loss event.
You cannot have a device that temporarily writes to RAM and tells the host computer "OK that's on disk now" (i.e. every SSD in existence with a throughput exceeding a few MB/sec) be reliable without an independent source of power to ensure that RAM reaches flash in every situation
Which is why things like cheap SD cards are notoriously unreliable, whereas Samsung SSDs are seen as decently reliable. What we really want is to get rid of these controller layers and let the OS directly manage the flash. But top of the line manufacturers are incentivized to decommodify their products to increase margins, and price-competitive manufacturers are inclined to stick to the same interface.
And it still doesn't solve the problem of the host buffers disappearing. What's the scenario, the host experiences a power-loss, but was somehow anticipating it and managed to stop writing to the SSD?
The best a database can do is prevent corruption. It cannot magically prevent data loss of writes that have never reached the platter or NAND.
>And it still doesn't solve the problem of the host buffers disappearing. What's the scenario, the host experiences a power-loss, but was somehow anticipating it and managed to stop writing to the SSD?
You solve the problem of host buffers disappearing by using fsync. The scenario is that fsync works correctly on powerloss.
Imagine you build an app consisting of 3 microservices. They are called Human, CPU and Disk.
The human sends a request via a website to the CPU. The CPU wants to save the host buffer in a database and sends a fsync request to the Disk. The Disk sends an "OK" response immediately but actually saves the data in the background. The CPU sends an "OK" response to the human. Everything is fine. Suddenly powerloss happens and the disk cannot save the data in time. The database is smart, it knows how to reconstruct some of the data until the point where the transaction log has been cut off. Beyond that though the data is gone and the "OK" sent to the Human is no longer valid.
Now imagine the same scenario with correct fsync. The CPU waits for the Disk and during a powerloss not only is the disk dead but the CPU is dead too and it therefore cannot send an "OK" response to the Human.
What if you don't use fsync? What if you pipe your data to /dev/null? Well, here is the tough news: Nobody can help you. If you don't write data to disk then it's gone.
Unsure of this (I would assume "it depends" and "probably not" because how else could it possibly know that anything is written to durable storage ever ever) but the idea is that if it didn't have to assume that life would be a lot easier.
> What's the scenario, the host experiences a power-loss, but was somehow anticipating it and managed to stop writing to the SSD?
If I understood your question correctly, databases and similar stuff write data in a way to try to solve exactly this problem, with write-ahead logs and such where you first write quickly and inexpensively to the log and then write to the database.