Welcome, Guest
Username: Password: Remember me

Search Micromat Forum

Keyword

TOPIC: Volume Optimization taking a very long time

Volume Optimization taking a very long time 02 Jan 2020 18:56 #11707

I have a couple of SATA hard drives internal to my Mac Pro, one boots to High Sierra and the other to Sierra. I have TTP 11 installed on the High Sierra drive from which the computer is now booted, and I am now running the Volume Optimization tool on the drive containing Sierra. The drive now being optimized is 750GB total capacity with about 500GB of files.

It's now 24+ hours into the optimization process but showing only 17% progress ... at this rate it will take almost a week to complete ... is this normal to take so long? Note: this drive's hardware checked out to pass all SMART tests and otherwise has been working fine up to this point.
The administrator has disabled public write access.

Volume Optimization taking a very long time 02 Jan 2020 20:33 #11708

There is no way to know how long an optimization should take. It depends on drive speed, bus speed, processor speed, and the exact distribution pattern of the file pieces (called "extents") and free space fragments on the volume.

The most efficient approach is to run the file optimization first, and then the volume optimization.

If you cancel the Volume Optimization, the program should finish working on the one file it is optimizing, update the disk directory, and then halt the process.
MicroMat Inc
Makers of TechTool
The administrator has disabled public write access.

Volume Optimization taking a very long time 02 Jan 2020 23:28 #11709

If you have another volume that is at least as large as the one you are trying to optimize, you might find this approach helpful, provided the volume to be optimized is not a bootable volume:

Optimize Using the Cloning Tool

After a volume has been optimized using the cloning tool, it should be possible to optimize it efficiently in the future using the disk optimizer, because the files will be in fewer pieces and the free space will be less fragmented.

If the volume to be optimized is a bootable volume, this approach is preferable:

The cloning tools are intended to allow copying data from one volume to another, but it is preferable not to use them to try to create bootable copies of bootable volumes. For that, I would suggest that you use either Carbon Copy Cloner or Super Duper! A bootable volume is not simply a collection of files on a volume. Several commands must be run to make the collection of files be recognized by the operating system as a bootable volume.

There are files that Apple recommends for exclusion from a bootable copy of a bootable volume. These files are excluded by both Carbon Copy Cloner and Super Duper!. Bombich has a list of these excluded files on their Website, while Super Duper’s log shows the exclusions each time the program makes a backup of a bootable volume.


The File Cloning tool can be used to copy files from one volume used to store files to another. It copies at the file level, and updates the disk directory of the destination volume as files are copied to it.

The Volume Cloning tool copies all of the bits from the source volume to the destination volume, including the disk directory and any errors it contains, and the data in the free space that is not currently part of a file. Because it copies all of the bits on the source volume to the destination volume, the destination volume must be equal to or greater in size than the source volume. Only if the two volumes are precisely equal in size can you use this tool to copy files from volume A to volume B, and then from volume B back to volume A. The advantage of this tool is that because it copies bits, it is faster than copying files.
MicroMat Inc
Makers of TechTool
The administrator has disabled public write access.

Volume Optimization taking a very long time 03 Jan 2020 21:10 #11720

micromattech3 wrote:
There is no way to know how long an optimization should take. It depends on drive speed, bus speed, processor speed, and the exact distribution pattern of the file pieces (called "extents") and free space fragments on the volume.

The most efficient approach is to run the file optimization first, and then the volume optimization.

If you cancel the Volume Optimization, the program should finish working on the one file it is optimizing, update the disk directory, and then halt the process.

Yes, I had run the file optimization first, however, thinking back, I'm not sure that it actually did anything.

I eventually cancelled the volume optimization after 48 hours when it had reached only 25% complete. I then re-ran the file optimization; it identified 392 files as needing optimization. After clicking "run", it counted-down the files, showing their names as it went, however, when it reached the end of counting files, it simply stopped and showed the job results as being "incomplete", "no files optimized (392 total files)" with no error message or reason for the result.

I rebooted my computer, and re-ran the TTP file optimization, however, the result was identical. I looked at the file names it displayed, and I saw none that were system files that should be locked, so this result is very unexpected. I am running TPP version 11.0.6, so this should have had the software bugs worked out by this time, correct?

Can you please advise why the file optimizer stops this way? Should I be running some other utility first / instead? Please advise.
The administrator has disabled public write access.

Volume Optimization taking a very long time 03 Jan 2020 21:41 #11721

Thanks for your clear and detailed report.

In order for a file to be optimized, there must be a piece of disk space that is both free and contiguous (all in one piece). You can use the Volume Optimization preview to see how large the largest piece of free, contiguous disk space is. It is identified in the graphic as "Largest". Then compare the size of that free space piece to the sizes of the files that appear to be ones that should be able to be optimized.

There are some files that cannot be optimized because of unusual permissions.

After checking the "Largest" free space extent, please send a message to This email address is being protected from spambots. You need JavaScript enabled to view it. . You will receive a reply by email, probably on Monday. Thanks for your cooperation and your patience.
MicroMat Inc
Makers of TechTool
The administrator has disabled public write access.

Volume Optimization taking a very long time 04 Jan 2020 13:44 #11724

On this same drive, the files needing defrag had sizes ranging between a few MB up to 4 GB. The drive has about 200 GB free space with several unused blocks over 1 GB. Unfortunately, the TTP file optimization made no attempt to consolidate even the smaller files, so this does not make sense, particularly that there was no report, error message, or guidance pop-up message given as to why the operation failed.

I then ran iDefrag version 5.3.1 on this same drive, and it proceeded as-expected. After a few hours, it reported that all files had been defragged. I then re-opened TTP, and it reported no files needed optimization, confirming that iDefrag had resolved the issue, so there were no special permissions or other file issues that should have prevented TTP from proceeding with the file optimization.

Are there some special settings within TTP that need to be changed to allow it to run file optimization, or is there a limitation in TTP that prevents it from running file optimization in certain circumstances?
The administrator has disabled public write access.

Volume Optimization taking a very long time 04 Jan 2020 15:03 #11725

I order for TechTool Pro to optimize one of the files about 4 GB in size, the largest piece of disk space that is both free and contiguous, shown as "Largest" in the Volume Optimization preview, would have to be at least as large as the file. There have been disk optimizers that did not have that limitation, because they moved around pieces of more than one file at a time. We decided years ago not to take that approach, so if the optimizer crashed, you should not lose more than one file.

Unless you can recall one of the files that was not optimized, and the exact size of the "Largest" free space block, there is now no way to investigate the problem, since you have optimized the files and the volume with another program.

It is possible that you have some files of a type the optimizer has not encountered before, and it left them alone.

I have explained the limitations of which I am aware. If you want to explore the issue further, please send a message to This email address is being protected from spambots. You need JavaScript enabled to view it. . Thank you.
MicroMat Inc
Makers of TechTool
The administrator has disabled public write access.
Time to create page: 0.352 seconds