|
As Andrew noted, FLASH-based SSD's have an inherent limitation in the
number of write cycles a FLASH block can sustain before it fails.
SSD's employ strategies such as "wear leveling" to mitigate the problem.
The good news is that as the capacity of SSD's increases, so does their
statistical lifetime in typical applications.
Whereas SSD's once were the province of only specialized applications
where the developer needed to be in total control of the total number
of write cycles to the disk, the capacities of the high-end devices now are such
that far less regard needs to be paid to their finite write cycle limits
when used with mainstream computing applications.
Andrew made mention of TRIM which is becoming part of the ATA interface
standard. Historically, a hard disk "knew" nothing about the file system itself,
which was handled by the operating system. From the perspective of the
disk, it "knew" how to accept commands to seek, read, write and to
perform some other tasks such as self-tests and low level formatting,
but nothing more. When a file is deleted on most operating systems, the
operating system moves the deleted blocks to a free list, but as far as the
hard disk was concerned, it didn't really "delete" anything, it simply
performed some more seeks and writes. So at the disk level, it had no
way of telling that the blocks of memory that were "deleted" were any different
to blocks that were in use.
What TRIM does is allows the OS to tell the drive that blocks are no longer
in use. For SSD's, this can assist it in a couple of ways. The drive can now
use the deleted blocks in its low level wear leveling strategy and it can
consolidate free blocks into segments large enough that can be erased
(when erasing FLASH, the architecture requires you to erase a large
chunk at a time).
Windows 7 apparently supports the TRIM command and my understanding
is that TRIM support might appear in a Vista service release.
|