C-Command Software Forum

Creating vs. Saving

I’m testing out DropDMG to use to create Disc Images of mounted Firestore FS-100 DTE devices in our digital video workflow. I have a couple of questions.

First, I want to test single and multiple (simultaneous) image creations from these devices. In other words, one DTE at a time or two at a time (we shoot multiple cameras). I’m curious what one should expect as far as the amount of time to create an image in either scenario.

For my first complete test, I created two images at the same time from two mounted DTE’s, fsA and fsB (with an equal 69GB on each disk), choosing volume B (internal RAID 0 with 2x500GB Drives) for fsB, and volume A (internal RAID 0 with 4x750GB Drives) for fsA… on a MacPro Dual 3Ghz machine with 8GB RAM.

The following facts are most relevant:

  1. The firestore uses a FAT32 volume (this is not optional).
  2. The disc has read/write access by default.
  3. I chose the following preferences:
    a. Format = .dmg Read-only
    b. Options = Use cusom icon, and Auto-open
    c. Save = Ask Later, and Promt for names (append date)
  4. I started fsA, then imediately started fsB

The results:
fsB took 41 min. to complete the Copy stage and then an additional 24 min. to Save. Total = 65 min.
fsA took 74 min. to complete the Copy stage and then an additional 14 min. to Save. Total = 88 min.

My next test will be a duplicate test, only I plan to swap the targets between them and test one at a time vs. simultaneously.

My questions are:

  1. What is happening between the Copy stage vs. the Saving stage? I ask because DropDMG mounted the volume temporarily before starting the Saving stage.
  2. Are there any settings I should change that would speed up the process?

DropDMG needs to mount the image in order to copy the custom icon and set the image to auto-open.

It would be a little faster if you turned off custom icons and auto-open. I’m working on some improvements to make disk image creation much faster for large images, but for now those are the only options changes to make it faster. Of course, since you’re dealing with digital video files you do not want to use a compressed .dmg format, as it would slow everything down for very little benefit in terms of disk space saved.

So then, is it technically finished at that point? It happened between the copy and saving stage. Should it take that much longer to save?

At that point, you have a read-write image with the finished contents. During the Saving stage, it compacts the unused space and calculates a checksum so that the contents of the image can be verified.