Crucial_CT256MX100SSD1, released for first MLC 16nm SSD.

Bought it possibly five years ago, and implemented for data storage
considerations three or more years ago. The smallest consideration is
then a 30G directory in storage stasis for the hypothesized time:

Info
- date: 12/4/2019
- process: Compare
- source: Crucial_CT256MX100SSD1:\com\
- reference: :\com\
- reference volume label: 960 EVO

Basic statistics
- time elapsed: 00:06:23
- overall transfer [kB/s]: 102,033
- folders processed: 1179
- files processed: 29856
- source bytes read: 37.3 GB (40,039,430,581 bytes)
- source average transfer [kB/s]: 148,098
- source clean transfer [kB/s]: 151,099
- reference bytes read: 37.3 GB (40,039,430,581 bytes)
- reference average transfer [kB/s]: 228,348
- reference clean transfer [kB/s]: 231,992

Errors
- errors: 0
- warnings: 0
- other: 0

The above mechanics are actually a little different, as I'm migrating
partitions for reconstruction. The Crucial is a copy from an original
500G plattered HDD, whereas the above operative is a bit-by-bit
comparison of the 29856 processed files --

Product: CDCheck
Version: 3.1.3.0 stable release
Author: Mitja Perko

Viz: Crucial to 960Evo, then 960Evo to comparison of files from
original HDD storage location.

If to say, estimably so within a minimal framework of 3 years
residence on the Crucial, that there's no bit-parity errors evident
(nor needless to mention perhaps a decade on the actual "source", a WD
from pre-Terabyte vintage).

I only work in FAT32, i.e. from OEM non-Microsoft partition utilities,
which I've several such to circumvent Microsoft later constraints in
deference to NTFS;- At and up to certain points, of course, where and
should the a)O OS declares FAT32 illegal, or b) for but a singular
instance of a NTFS drive permitted files not normally approaching 4G,
at FAT32 limits, and beyond.

As I would as well realize a SSD ought not be unplugged needlessly
from an otherwise active state SSD controllers would normally engage
to maintain their data health status. (I do however minimize OS
augmentation of such routines through such as TRIM command
initiations;- as some references are given to understand they're as
well a contingency of the controller itself in a fallback-state,
usually run in duplicity after a specific time state of SSD
inactivity.)