1.92TB Toshiba SATA SSD 1DWPD Under 400

brianmc

New Member
Jun 25, 2018
29
7
3
Isn't the Crucial consumer PLP totally fake PLP? I've always thought the "real" PLP is the normal one that when power is cut can dump data from the on-drive DRAM to NAND safely.
 

matthew5025

New Member
Mar 21, 2016
23
18
3
I've been trying to figure that out myself recently. Here is what I've found so far. There appears to be two general types (probably an over simplification), one is end-to-end. If the computer sends data to the drive it can be considered safe. The data is protected through the ENTIRE write process. If the power fails at any point all data is flushed from any buffers to the nand and no corruption occurs. I would call this "real" PLP and it's a requirement for certain types of deployments.

The second type (PLP lite?) only protects data at rest. The SSD is constantly moving data around which puts already written data at risk (look up how an SSD writes in large pages, causes all sorts of weird issues). With PLP lite any data already written to the nand is preserved properly during a power failure. Any data in any buffers (DRAM usually) is lost.

This has really started to irk me, there have been numerous companies that have claimed PLP while only actually offering PLP lite. I think Crucial had to change their marketing a few years back because they claimed a consumer drive had full PLP when it had just enough capacitance to keep the data at rest from corrupting.

Hope that didn't confuse things further!
The explanation for partial PLP is correct in the fact that partial PLP only protects data at rest, but it has nothing to do with the SSD moving data around.

Recall MLC stores 2 bits per cell, and when writing to a page, the SSD will write to the lower page (as it's easier and faster) then the upper page. The reason programming is done in two stages is to reduce cell-to-cell interference.

When programming the upper pages, if the power is unexpectantly cut, it's possible that the voltage ends up at an incorrect level, which could corrupt the lower page (usually data written some time ago)

For partial PLP, upon detection of an unexpected power loss, the controller will stop all operations and utilise the charge in the capacitors to return the voltage of the lower page back to the original level, ensuring that the data in the lower page remains intact.

Data buffered in the DRAM including data that has been acknowledged to the host as written will be lost.
 

BackupProphet

Well-Known Member
Jul 2, 2014
799
285
63
Stavanger, Norway
kingmakers.no
Data that has been acknowledged as written should never be lost, PLP or not. That is the whole purpose of using fsync or FlushFileBuffers. If kernel developers or storage vendors doesn't honor this, they will never be taken seriously for data storage. It is important to honor this as it could cause serious data corruption by messing up filesystem metadata.
 

matthew5025

New Member
Mar 21, 2016
23
18
3
Data that has been acknowledged as written should never be lost, PLP or not. That is the whole purpose of using fsync or FlushFileBuffers. If kernel developers or storage vendors doesn't honor this, they will never be taken seriously for data storage. It is important to honor this as it could cause serious data corruption by messing up filesystem metadata.
To quote micron themselves:

Data in flight also refers to data that has been temporarily buffered or cached in volatile memory, acknowledged as written back to the host, but not yet committed to the NAND device.
In SSDs used for client computing, data-at-rest protection is usually sufficient in the event of an unexpected power loss.

From Anandtech review of the M600, referring the the MX100 PLP:

Any ongoing upper page program will not be completed and obviously all data in the DRAM buffer will be lost, but old data will be safe.

If you're really particular about committing DRAM to NAND, you should only get DRAM SSD with tantalum capacitors. Ceramic capacitors simply are not sufficient. Afaik, very little client ssds have them.
 
Last edited: