Understand SSD
- page 01: Flash memory
- page 02: MLC and SLC
- page 03: Sectors, pages, blocks...
- page 04: Wear-leveling
- page 05: TRIM
- page 06: Garbage collector
- page 07: Every day usage
- page 08: Conclusion
Every day usage
Enough theory, let's look at a more practical point of view, and some tips to optimize performance of SSDs depending on their specifications.
Aligning partitions
File systems are separated into clusters of usually 4 KB. For optimal performance, limits separating sectors should be similar to those defining pages and blocks to avoid unnecessary rewriting procedures. To ensure such alignment, the partition must be properly defined and should start at a logical address being a multiple factor of the size of pages, and preferably of the size of blocks too. When used in RAID0 or 5, one would also favor alignment of RAID strips too.
This point is particularly important for SSDs with low performance levels, such as those based on Jmicron JMF602. Tests have shown the huge impact on performance when using such SSDs with Windows XP with default configuration (partitions starting from the 63rd sector corresponding to the middle of a page) and a Windows XP version with partitions realigned from the 64th or 128th sector.
Windows Vista and Windows 7 use a 1 MB alignment, a system compatible with current SSD even with large size clusters.
For Mac OS X, the alignment of the EFI partition of 200 MB is set to 512 B, an inconvenient choice for clusters with a 512-bit partition, while the first partition of the disc is then aligned at 204 802 KB, optimal for 4 KB clusters as most of the default size used on SSD for Mac OS X.
Avoid unnecessary writing procedures
If possible, you should avoid writing temporary or cache files (such as those from web browsers) on a SSD. Such writing steps will generate many erasing steps, and consequently accelerate aging of the cells. By increasing erasing procedures, it will also generate unnecessary writing steps and bring performance down. For temporary files, they are usually not written on the drive if there is enough space in RAM and if the application is properly coded to flag such files as temporary when creating them. The OS should then do its best to store them in cache file without requiring writing them on the volume.
For applications not able to manage temporary files, the best solution is to used a non persisting RAM disk. This is also true to cache files, as they will be written only once every time the computer is stopped. In addition, performances in reading and writing modes will be dramatically improved. Additional information about RAM disk on AMc OS X and Windows can be found here.
If you do not have enough RAM to create a RAM disk, then you should organize files in order to store cache files on the SSDand temporary files on a disc-based HD.
Do not defragment
On a disc-based HD, logical fragmentation of the file system correspond to a physical fragmentation, and consequently decrease performance. On a SSD, there is no link between logical and physical fragmentation and the first one has almost no impact on performance, while the second is not improved by defragmentation applications. Even worst, a logical defragmentation might increase physical fragmentation and lead to accelerated aging of cells.
What to do with the swap file?
As a basic rule, one should define the amount of RAM in order to avoid swapping, with a disc-based HD or a SSD. IF you cannot avoid swapping, then store it on the SSD. Statistical studies performed by Microsoft have shown that with Windows, 98% of the swap-related accesses are performed in reading mode, with 67% of them for less than 4 KB and 88% of them for less than 16 KB. One the other side, 62% of writing procedures are related to files larger than 128 KB while 45% of them weight more than 1 MB (blogs.msdn.com). Such access profile seems optimal for a SSD, perfectly designed for such small reading requests (even if there are heavily fragmented), while performance should not be much affected by writing large files.
Follow OS upgrades
As SSD is now trying to become a new and standard device on the consumer electronics mass market, all OS will be modified to benefit from their specific performance, and optimizations should be integrated in future updates of the most common OS.
Windows 7 will be the first consumer-oriented OS to officially offer such SSD-specific optimization. It will be able to differentiate disc-based HD from SSD (by querying the rotation speed) then will bring support for different optimizations (TRIM command, cache management during writing procedures, etc.), so features might be deactivated if the SSD is offering high performance levels (Prefetch, Superfetch, automatic defragmentation).
For Mac OS X, Apple did not announce any optimization for SSD in Snow Leopard yet. However, as Apple already offers hardware models featuring SSD we would be surprised if the future OS will not include any tricks to improve SSDperformances. We should know in couple of months, and maybe Snow Leopard will be the first consumer-oriented OS to bring native support for SSD.
Journal
Most of the main current file systems (HFS+, ext3, NTFS...) are journalized, so they store extra information in addition to the files themselves. Those additional parameters are designed to maintain integrity of data in case of crash, or to track the access path of files. All those journals have a tendency to generate extra writing procedures. However, it is not recommended to inactivate them as they can prevent you losing data if the drive crashes. Users of Windows will be able to deactivate 2 functions of the NTFS file system without impacting reliability of journals
Why not using a file system designed for flash memory?
There are at least two different file systems specifically optimized for flash memory based storage unit: JFFS2 (Journalized Flash File System 2) integrated in Linux kernel and the exFAT introduced in Windows CE 6.0 and Windows Vista SP1.
It is not necessary to use such specific file systems with SSDs. Indeed, they mostly bring support for wear-leveling at the file system level for flash-based units not able to manage this function at the hardware level, as it was the case in previous/older memory cards and USB key.
