Happy new user of a 160GB 320 with latest firmware that has been successfully cloned
from a previous 160GB hard disk.
However, when I run the toolbox cleanup on a 40 GB partition (not the largest partition)
which is 60% full (containing two files are over 10GB) the toolbox utility quickly reaches
12% and stays there forever. The partition fills up to 100% with the cleaning 0 filled files
but the CPU usage stays at idle as does the hung toolbox. I've performed a boot time
check disk and all is OK.
All other partitions are ok (although none have 10GB files) and there is nothing else running on the
partition causing a hang.
A previous SSD Toolbox discussion metioned the optimiser getting hung at 12% so maybe there is
a common issue.
If I manually kill the optimiser and remove the optimiser 0 filled files everything seems ok
(until I try it again on this partition that is).
As I said, the other partitions are fine just this one which has unusually large files.
I'm still having the same problem with my 300GB 320. The optimizer hangs at 12%, it shows "running" in blue text, but the run and schedule buttons go active again as if the utility had completed.
Is the partition giving you trouble the first partition on the SSD? Mine has a single partition on it.
There are 5 partitions, this is the second partition showing up as D:
I have exactly the same issue - the tool appears to not complete the operation properly (shows running 12%) whilst enabling the Run and Schedule buttons for further operations (I suspect the error is trap'ed and silently ignored to enable the tool to keep in operation).
The partition then shows 100% full with the zeroed *.bin files remaining.
Ad-hoc solution is to run the Optimizer and manually delete the *.bin files on this partition only (all other partitions work OK).
If there was a log file option to capture the trap error message that would help a lot: this is one for the developers.
I've tied it down to the Allocation Unit Size (as windows puts it).
For me, the SSD Toolbox 3.0.2 will always hang (it actually crashes) if the
Allocation Unit Size is 32K or 64K: default (which is 4K) works.
I haven't tried all of the other sizes to narrow it down further: this is an exercise for
the software guys if they can reproduce it at intel.
Partition size is: 25,302,134,784 bytes if it is connected with Allocation Unit Size
not being a multiple of the partition (my hunch)).
Bingo! I was using 32K when I was having the issue...I erased the SSD and put it into a new build (Win 7 64) with the default allocation unit size, and the SSD tool worked OK there (though not necessary with Win 7).
I do wonder though...there's no evidence here that anyone at intel has either read this or has any interest in fixing this bug...