I contacted SCSC about Scannerz and support for SSDs. You CAN test an SSD with Scannerz, but the "historical report" may not be of much value to you. The "historical report" is intended to typically indicate a performance slow down on a real (mechanical) hard drive where a loss of performance due to slow degradation over time would show up as changes in their relative performance indices. Because SSDs use varying and changing types of wear leveling and TRIM, and its operation and timing can't be predicted by them, it might tend to report inaccurate results in the "historical report."
That said, they took a look at this thread and suggested that the fact that you seem to be correlating movement with the appearance of the problem to them suggests a connection fault, such as a faulty cable, faulty connector, or cracked traces in the logic board. Traces in the SATA cable on those units can develop micro cracks and provide intermittent contact, which can yield I/O errors or irregularities during a Scannerz test, and of course during actual use as well.
They suggested you download their demo (limited to 0-10G sweeps) at:
http://www.scsc-online.com/Scannerz_files/Scannerz Demo.dmg
and do the following:
1. Start a scan on the unit in cursory mode. Keep in mind that with an SSD I assume you won't have a whole lot of time because I assume it will scan quickly and the demo is limited to 10G.
2. Click on the "Test Status" tab.
3. Monitoring the "Test Status" tab, start lightly tapping on the bottom of the unit near the vicinity of the SSD and cable.
4. If irregularities or errors are showing up that can be correlated to the tapping, then you've got an electrical fault in the system somewhere. This will be a cracked logic board trace, intermittent contact in the SATA cable, or connector problems.
5. If irregularities or errors are showing up at the exact same places in the scan, then you've got bad or marginal memory blocks in the SSD, but the demo only scans to 10G so the likelihood of this being the problem and being caught isn't that high.
Scannerz monitors for I/O errors and timing retries. If there are temporary disconnects due to something like a cable fault, cracked logic board trace, or intermittent contact in a connector, the system will try and re-try until electrical contact is re-established (sort of like a loose light bulb flickering on and off) at which point an irregularity is acknowledge by Scannerz, or if contact isn't re-established an I/O error will occur and will show up as an error in Scannerz. I would think in the latter your system would lock up, but that's me guessing (again).
🙂
The difference between a drive problem and a system problem is that drive problems, like bad sectors, will always occur at the exact same place during a drive scan, but if they're caused by bad cables, logic board traces, or connectors they won't be tied to a specific region of the drive, they'll happen randomly.
They also suggested that if you have the free space on your drive you might want to split the volume and try something like a basic installation of Snow Leopard or Lion on the smaller, new volume to see if the problems disappear.
One caveat about Scannerz: It disables Spotlight indexing during a scan. When it ends, Spotlight will start re-indexing the entire system on Mountain Lion (it didn't seem to do this on Snow Leopard or Lion, just incremental updates.) SCSC makes a product called "SpotOff" which allows users to enable/disable Spotlight indexing. It was intended to be used on PPC units with Leopard because Spotlight was so obnoxious on those systems and it seemed to be cleaned up in Snow Leopard and Lion because they appeared to do incremental indexing. Guess what? Now it's apparently a "hot selling product" since ML has been introduced. Can you guess why?
As an FYI about ML bugs, today all I was doing was some e-Mail and basic web browsing. The system came to a crawl. I checked Activity Monitor and the system was using all 4GB or RAM, most of it in the kernel_task, mds, and Safari Web Content. In fact, as I write this, Activity Monitor is reporting that I'm using 429M for the kernel_task, 234M for the mds process, and 152M for Safari Web Content. I've got about 100M of "inactive" memory, and the total sum of memory used is slightly over 2GB.
That's a lot of memory to be used when the only applications I'm running are Safari and Activity Monitor. I swear to God this thing worked better when I had 2G installed in the system.
I've never had problems with an Apple OS like this before. I'm seriously considering moving back down to Lion or Snow Leopard. I wouldn't rule out the OS being the cause of the problems at all!