Comments on: SSD Performance without ATA Trim

By: Matt

Matt — Sat, 24 Jul 2010 21:55:59 +0000

Salut, one would hoped the 25E being a SLC device wouldn’t of had this issue… Yes, I normally create and delete the disk image straight away, repeating the process twice.

By: Guido

Guido — Sat, 24 Jul 2010 21:35:00 +0000

Interesting! Got the same problem with a 50nm X-25E. One question though: creating dummy.img once and deleting it immediately afterward is the right way to proceed?

By: Matt

Matt — Thu, 13 May 2010 23:11:21 +0000

It’s worth pointing out that using the Intel SATA drivers instead of the Microsoft supplied ones does also help performance. http://www.intel.com/p/en_US/support/highlights/chpsts/imsm

By: Matt

Matt — Mon, 08 Mar 2010 04:53:41 +0000

Thanks for the tip, I've tested this quickly on my set-up (X18-M 50nm) and it does seem to help (haven't run numbers on it yet though). I'm guessing that the only difference between an SSD page that is empty (either raw or via trim) and one that is filled with zeros is the usage information stored by the controller. It would make sense for the controller to know if the page was completely filled with zeros, as there's no point erasing an already empty page. Knowing this certainly makes the lack of trim more bearable. The equivalent command to generate and delete a blank zero filled file on Windows (XP, Vista and 7) is:

fsutil file createnew dummy.img 18
del dummy.img

You could also use the virtual hard disk tool in Virtual PC, selecting the 'fixed sized' option. This way provides a GUI and doesn't require admin rights like 'fsutil' does.

By: Darrell

Darrell — Fri, 05 Mar 2010 20:59:38 +0000

There is a somewhat easier solution that may be worth trying before the above process. I have confirmed that it works on my Intel X-25M 50nm SSD. You need to make a large dummy file of zeros, that is slightly smaller then the amount of free space on your drive. In this command i set count to 18 because i had 18.7 gb free:

dd if=/dev/zero of=dummy.bin bs=1000000000 count=18
rm dummy.bin

I did this a few times and got my avg write speed from 32mb/sec to 67mb/sec. I think it works because it forces the controller to repack the sectors more efficiently.