I bought a couple of new big hard drives, and decided it was time to re-organize all of my computer’s disks. I have 3 hard drives inside my Mac Pro, and nine (yes, nine!) hard drives sitting on a nearby table.  Most of these disks are partitioned into multiple smaller regions. I have so much storage because I want every partition to have a local backup (in addition to backups from Backblaze, an automatic cloud backup service I pay for). So each internal drive has a corresponding backup partition on one of the external drives, and each external partition also has a backup (the backups get updated automatically every night in the wee hours by a program called SuperDuper). This organization works well for me because I need some partitions to be fast, some to be secured, and so on.

Moving everything around properly was risky, because if I messed it up I could lose both my original and backup data. To reduce the risk, I wrote a Processing program to let me first simulate (and debug) the re-organizing process, and then provide a step-by-step guide for actually moving stuff around.

There are 2 drives with 3TB, 3 with 2TB, and 3 with 1 TB, plus one of just 500GB. You can see the different sizes in the widths of the boxes in the screenshot. When I bought the new 3TB drives I decided I should re-organize all of my data so that it was more sensibly distributed physically. One physical drive could hold nothing but backups, for example, rather than a mish-mash of primary and backup data. Once I had a plan for how I wanted the new setup to appear, I realized I had a problem: getting the right partitions on the right disks was very much like a sliding-block puzzle. Some of the drives had to be re-partitioned into new sizes, but I’d have to move the information off of them first onto another drive, which itself had to have enough clear space, and so on. The easy way would have been to just copy everything onto the big new drives, erase the others, and copy it all back, but that would have taken forever. I wanted to move the data only once. Because I was moving both original data and backup data, if I screwed up, I could be really sunk, and my precious data gone (except for the cloud backup, of course, but that’s a last resort).

So I wrote a program in Processing. It shows me each drive (the horizontal boxes), and its partitions with their names. The top row shows the “before” state, the bottom row the “after” state. Color-coding shows me which partitions have valid data (cyan), and which are empty (yellow). In the snapshot above, you can see the magenta-outlined partition on the fourth disk from the top. This is the “source” partition. It’s about to be copied to the “destination” partition, shown as the cyan-outlined box on the seventh disk. When that’s done, the source partition will turn yellow, and the destination partition will turn cyan. When everything’s complete, I’d expect the top rows to all be yellow (every partition has been moved) and most of the bottom partitions to be cyan (holding active data). Some of the new bottom-row partitions could still be yellow, because they’re for new data.

The value of this is that the program checks everything at every step to guarantee I haven’t overlooked anything. I never write into a partition that holds active data, and I never read from a partition that doesn’t hold active data. Running through the process a few times in software revealed a couple of minor slips in my original paper-and-pencil plan, which could have been catastrophic.

To me, this is a great example of how a computer program helps us tackle a complex, dangerous task and turn it into something that’s easy and guaranteed to work properly.

Edit added later: Once I started implementing this plan, I quit. After getting the whole ball rolling, I found that it would have taken more than a week of 24-hour copying to reorganize the disks as I’d planned. And of course using the computer during that time would have only slowed it down more. Even after putting in all this effort, it just didn’t seem worth the hassle. The motivation for moving things around was largely aesthetic, and I felt that didn’t justify the time, plus the wear on tear on the drives. So I let everything remain where it was. But it was a good plan!