Intel Updates SSDs, Supports TRIM, Faster Writes

MojoKid writes "Intel has just released a firmware update for their 34nm Gen X25-M solid state drives that not only boosts sequential write performance, but adds support for the TRIM command as well. A performance optimization tool is also being released today, for users of Windows Vista and XP, who won't be able to take advantage of TRIM. After being flashed with the new firmware update, Intel's 34nm Gen 2 X25-M 160GB drive offered increased performance in a myriad of benchmarks shown here, and sequential write performance was increased on the order of 30%."

Comments

A better write up at anandtech

[Zebadias]

http://www.anandtech.com/storage/showdoc.aspx?i=3667

Re:A better write up at anandtech

[Vigile]

Here is PCPer.com's post on this update:

http://www.pcper.com/article.php?aid=805

Re:Great

[tepples]

Now what file systems support TRIM?

Any file system whose checking program supports retrieving a list of cluster ranges that aren't in use can be made to support TRIM. These include any FS that uses a "bitmap" to record sector allocation (e.g. HFS or NTFS), as well as any that use a linked list of cluster numbers (e.g. FAT32, exFAT).

Re:Great

[TheRaven64]

Well, not exactly. The filesystem driver in the OS needs to support it. It's not something that you can just support for every filesystem easily, because each filesystem keeps track of which blocks are in use and which are not in a different way. An OS will support it by exporting a trim command from the block driver level, which will be ignored by older drivers and mapped to the SATA TRIM command on drivers for newer controllers. Each filesystem will then be responsible for actually issuing these commands.

Re:Great

[bill_mcgonigle]

Now what file systems support TRIM?

ext4, but the block layer needs to handle it too. There was some LKML traffic a couple months ago about smart designs for this - it's probably not in current distro releases yet. TRIM can be very expensive if not well-optimized (the non-optimized demo took a half hour to delete a kernel tree with TRIM on a supporting SSD) and the right thing to do may depend on drive model capabilities. The moral is it's not worth doing poorly, and doing it right may require some re-plumbing. But the upside is that Linux ought to be very fast and efficient about it when it lands because smart folks are making sure it ships when it's ready, not by some arbitrary date.

Re:Intel change is great, but...

[Spad]

Defragging SSDs is not only mostly a waste of time (Seek time is the same regardless of where the data is physically on the drive so unless you're dealing with heavy fragmentation of large files it won't have any effect), but it reduces the lifespan by needlessly reading and re-writing data all over the place; there's a good reason Windows 7 automatically disables defragmentation for SSDs.

Bricked 30% faster than before!

[ozbird]

Oops.

New firmware was pulled from Intel website

[lbschenkel]

Intel pulled the new firmware from its website because it would brick the drive in some machines with Windows 7: http://www.buzzbox.com/preview/intel_pulls_ssd_toolbox_for_killing_drives_under_windows_7/?id=154783

I have Windows 7 and a X25-M G2 that I was going to update but I gave up after I found via Google a lot of forums posts from people who bricked their drives with the new firmware.

A word to the wise!

[rabtech]

WARNING: Intel has pulled the firmware because there appears to be a chance of bricking the drive. Users report that the firmware updates successfully, but after rebooting Windows detects changed hardware, installs drivers, and after rebooting again the system BSODs and/or won't boot at all. The drives appear to be bricked unless reformatted.

I have one of these drives and I'm holding off until the dust settles.