More on TRIM
The first thing to throw out there is that TRIM is not yet finalized.  There is currently a mini version of the HD DVD vs. Blu-ray war going on amongst the standards guys.  Remember, TRIM was originally geared towards huge SANs employing storage pools shared across many users.  In this context, TRIM is a way to free up blocks of storage for others to use.  There is an alternate form of the standard for the ATA spec (SATA included), which will likely end up being implemented in SSDs once the standard is settled on.  A good gauge of this will be when Microsoft finally adds it to Windows 7 (it’s not in there yet).

Bust out your calculators

I’ve recently noted some speculation on how TRIM is supposed to work and thought I would chime in a bit.  The linked page suggests that TRIM will cause a drive to perform a read/erase/write cycle.  Given Microsoft’s requirement (page 13) of a TRIM turnaround of 20 ms and the maximum TRIM range (page 7) of that command being a single 16 bit word, meaning 65536 sectors (32 MB), an SSD would have to be capable of internal read/erase/writes at a rate of nearly 1.7 GB/sec (1638 MB/sec).  Nothing short of an ioDrive is going to hit those speeds any time soon, so it is a safe bet TRIM will not work this way.  Besides, writing over every block of deleted data would make data recovery impossible and would subvert wear leveling entirely.  Deleting a batch of small files would take just as long as it would to write that same batch of small files to the drive, imposing an unnecessary delay in completion.

How it really works

There is no correct answer for this one as of yet, and what actually happens will largely depend on the implementation.  Marking the TRIMmed area as free space but maintaining the table entry will help with later data recovery efforts and accelerate subsequent writes, but will maintain the added overhead of having to track the LBA pointer to that location.  Deleting the entry entirely will reduce overhead, but the TRIMmed data will be permanently lost the instant it is deleted, since the drive will no longer be able to associate the LBA with a flash memory address.  This is the sort of conundrum being hashed out by those working on the specification.

Jumping the gun

The Indilinx guys have gone ahead and implemented a draft form of TRIM and OCZ has released a (very) beta version of a TRIM tool for use with their Vertex series drives.  The bonus is this tool works under XP and Vista, and if run occasionally it can provide a similar performance benefit when compared to what should be possible with Windows 7.  Riding the bleeding edge has its detractors: As of this writing the tool causes severe data corruption in 64 bit environments.  I can understand the pressure on OCZ, as my testing shows they tried so hard to fix the stuttering issue that long term write speed suffers considerably.  The only way to correct such a strong bias towards short term performance is to perform occasional purges of the drives LBA remap table.  The Vertex will be revisited and covered in greater detail once their firmware and tool are a bit more refined.

« PreviousNext »