Merging an Empty HFS Partition Into Active Data on macOS 10.8.5 Mountain Lion With CoreStorage
Reclaiming space stuck on the wrong side of the partition table, with an undocumented diskutil command
diskutil resizeVolume / mergePartitions can’t merge them — filesystem resize only grows forward into trailing free space, never backward. CoreStorage sidesteps this because it pools partitions logically instead of growing them in place. The undocumented diskutil coreStorage addDisk command works for this on 10.8.5 — but resizeVolume‘s “fill everything” shortcut (0) does not work on this OS version — you have to pass an explicit byte count. Full working sequence and output below.The setup: a disk with two partitions —
disk1s2 (90.8GB) was empty. disk1s3 (658.8GB) held all the active data. The goal: reclaim the 90.8GB and end up with one combined ~750GB volume, without wiping or cloning the data partition.
The obvious approach — delete the empty partition, then grow the data partition into the freed space — doesn’t work here, and it’s worth understanding why, because the failure isn’t a bug, it’s how partition resizing is fundamentally designed to work.
diskutil resizeVolume and diskutil mergePartitions both grow a partition by extending its trailing edge — moving the boundary that follows the partition further out on the disk, into space that comes after it. Neither can move a partition’s starting position. Doing that would mean physically relocating every block of an existing filesystem to a new starting offset on disk — not a metadata edit, but a full block-level move — and that’s simply not what these tools do.
That’s exactly the situation here: the empty space (90.8GB) sits before the data partition, not after it. Deleting the empty partition just leaves dead space that the data partition has no native way to absorb. This is a well-documented limitation reported independently by multiple users hitting the same “partitions in the wrong order” wall — see the Ask Different thread on this exact problem.
mergePartitions doesn’t get around this either: its own man page says whichever partition you list first keeps its data and gets grown — but “grown” still means grown forward. If the partition with your data is physically the second one, this hits the same wall dressed up in a different command.
CoreStorage is Apple’s logical volume manager (it’s what powers Fusion Drive and FileVault 2 under the hood). Instead of a single filesystem occupying one contiguous span of a disk, a CoreStorage Logical Volume Group (LVG) pools one or more Physical Volumes (PVs) — which can be any partitions, anywhere on the disk — into one logical address space. A Logical Volume (LV) inside that group is addressed logically, not by physical position. Because of that, two partitions can be pooled together into one usable volume regardless of which one is physically first on the disk.
This is why the fix here isn’t a resize at all — it’s converting the data partition into a CoreStorage volume, then adding the empty partition into the same pool.
Starting layout:
Data is preserved — this is a live, in-place conversion, not a wipe. disk1s3 becomes a CoreStorage Physical Volume, wrapped in a new Logical Volume Group, with the original filesystem now exposed as a Logical Volume at disk2.
addDisk is undocumented — it doesn’t appear in Apple’s diskutil man page and isn’t officially supported. Reports of its reliability across different 10.8.x point releases are genuinely mixed — broken on 10.8.2, reportedly fixed on 10.8.3, then reported broken again by other users afterward. Test on a disposable disk before trusting it with real data. It worked cleanly here on 10.8.5.After this step, diskutil list confirms both partitions are now part of the same CoreStorage group:
And diskutil coreStorage list shows a single LVG with both PVs and ~90.6GB of free space sitting unused inside the pool:
The space is pooled, but the Logical Volume itself hasn’t grown yet — that’s the last step.
The diskutil coreStorage resizeVolume man page (at least as documented on more recent macOS versions) says you can pass 0 as a shorthand for “grow to fill all remaining space in the LVG.” This does not work on 10.8.5:
The workaround is to calculate and pass an explicit byte count instead:
(Deliberately left slightly under the LVG’s total 749,678,182,400 B to leave headroom for CoreStorage’s own metadata — don’t try to claim every last byte.)
resizeVolume, mergePartitions) can’t reach it — this isn’t a bug, it’s inherent to how in-place filesystem growth works.addDisk can pool partitions regardless of their physical order, because it’s a logical layer, not a physical resize. But it’s undocumented and unsupported — back up first, and ideally rehearse the whole sequence on a throwaway test disk before running it against real data.resizeVolume‘s 0-for-“everything” shortcut, as documented on later macOS versions, does not exist on 10.8.5. Use currentSize + freeSpace in bytes instead, with the b suffix, and leave a small margin under the LVG total.The complete, unedited terminal transcript (including all diskutil list output at each stage) is available as a PDF here: resize-partition.pdf