I backed up 121 GB from two partitions (one XP and the other Win7) using Acronis TI 2010, reset the drive with HDDErase 3.3, and booted from the Acronis recovery disk to reload from an external sata backup drive. I intended to leave it to reload overnight, however the temptation to stay won out when I saw the Acronis estimate of only 30 minutes to restore 121 GB! The drive light on my Dell D620 Core2 Duo laptop hardly flickered during the restore..it was on solid!
Passmark Performance Test v7.0 registered a DiskMark score of 727 on my anemically-bused laptop (some IDE-to-SATA gimmick that Dell dreamed up). Anyway, I will rest easier knowing that my write performance is not degrading (much?) over time.
I do have a riddle for the community, though. Trim is effectively an OS driver that shifts SSD read-modify-write operations in the time domain so that, from a user perspective, those time-consuming operations are performed at "off-peak" times. I assume that a file deletion triggers a read-modify-write cycle for one or more blocks at the time of the deletion. This raises the question of the result when a multi-boot user boots into a non-Windows 7 partition (say...XP) and deletes data that is visible to both XP and Windows 7. Obviously XP cannot perform trim operations for such deletions. But, upon re-boot into Windows 7, is the trim algorithm smart enough to scavange the file system for files deleted since its last boot in order to trim those "foreign" deletions from the SSD?
And if not, why not, darn-it?!
Bruce
