said by trparky:
Did you read my post about how the failure of the SSD seemed to coincide with an issue of the TRIM command to the SSD?
No, that comment hadn't shown up by the time I wrote my explanation. This just brings even more nonsense into the picture:
1. How are you issuing "TRIM commands" for the drive on a nightly basis? On Windows Vista onward you should not
need to do that (presumably you're running the "Intel SSD Optimizer") using Intel's SSD Toolbox; that's intended for XP systems which do not offer native OS-level TRIM (see below). You should not be doing this daily unless you are doing massive
amounts of I/O every day (I'm talking maybe 60-80GBytes of writes and deletes, daily, on a 100-120GB SSD).
are you doing this on Windows 8? Since Windows Vista the OS has had TRIM capability natively within the ATA I/O subsystem driver. The OS takes care of this natively, and cleanly, for you per every I/O delete operation (or may submit large consecutive/linear LBA blocks in an optimal way, rather than one at a time -- both methods are fine). You should let the OS take care of this for you; it will do a more efficient job and consistently 100% of the time.
3. Are your partitions on your SSD properly aligned to either 1MByte or 2MByte boundaries (or possibly other multiples of (2^10)*4)? Windows Vista onward has ensured that, but if you did something like use XP back in the day, then installed Vista (including a clean install but without
deleting the existing partition (not the same as formatting the existing partition; that would not change the alignment)) or newer, then that would explain very bad TRIM performance in general. I'm not talking about 4KByte alignment here, I'm talking about NAND erase block size alignment (which is represented by N number of sequential NAND pages, and the NAND page size varies per SSD brand, model/device, revision, and lithography. Most manufacturers do not disclose this info, which still to this day pisses me off). You can read about the ill effects of non-NAND-erase-block-aligned partitions here (read, do not skim): »wiki.laptop.org/go/How_to_Damage ··· e_Device
4. How much free space did your Intel SSD have before
you deleted 10GB of data off of it, and what capacity is that SSD? You should always keep roughly 30% of free space on the SSD.
5. Have you ever done something like a "full format" on the SSD, i.e. every LBA ("sector") written to with data (or zeros)? If so, this would explain awful performance of the SSD, especially during TRIM or GC operations -- the FTL is completely maxxed out. Do not do this on an SSD. ATA-level Secure Erase is the proper way to do this.
6. Did you ever look at any of the SMART statistics on your Intel SSD? If so, do you have that data somewhere (screenshot, etc.)? It would give me some indication of its internal state.
TRIM in general is an expensive operation, and likewise, GC (garbage collection) takes even longer. The drive can
go catatonic during this state, to the point where kernel/device drivers may think the underlying device has "fallen off the bus" (in actuality the kernel/drivers hits an internal I/O timeout and then kicks the drive off the bus itself). Any OS will see this. The timeout on FreeBSD is 30 seconds with a 5-attempt retry count. What Windows uses as a timeout depends on the underlying storage drivers; if you're using Microsoft's AHCI, you would need to ask them or look through MSDN. If you're using Intel's RST drivers (be sure to state what version) you would need to ask Intel what the value is.--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.