5

I used Disk Utility to create an empty encrypted sparsebundle on a FAT volume A. It contains an HFS volume B. I am running on Snow Leopard.

The DMG now pretty much fills A, and I'm fine with that. This is not about space on A.

When I delete files from B, the free space Finder shows for B does not change, and it refuses to copy new files onto B. Emptying the trash doesn't help. Ejecting doesn't help. But verifying (not repairing) B in Disk Utility does, even though no errors are found.

This is a bit of a chore. How do I get better behaviour?

Improve this question
6
  • Lion or Snow Leopard? You should get the space back when the next compact event happens.
    – bmike ♦
    Sep 22, 2011 at 15:36
  • Really - if hdiutil compact doesn't reclaim space, then your filesystem is possibly wedged or damaged. Have you repaired the image to rule those out?
    – bmike ♦
    Sep 22, 2011 at 17:13
  • This is about the volume inside the image, so compact is irrelevant. For all I know the problem might be the same if the volume were on a physical disk instead of in a DMG. I did not repair because verify doesn't find anything.
    – Tobias
    Sep 22, 2011 at 17:34
  • In my experience, the space is shown as used since it needs a "compact" or a repair and not despite the appearance that a verify came up clean. But then again, I also don't have the misbehaving image so I might be off base on my guess as to why you are seeing this normal but unwanted behavior.
    – bmike ♦
    Sep 22, 2011 at 21:41
  • So there are 70MB free on A, and Finder shows 39MB free on B. If I verify in Disk Utility, A does not change but B jumps to 2.6GB. The same happens if I copy the DMG to a disk with more free space. compact makes up 2GB on A and only 2GB on B. Verifying again makes the missing 600MB available until I eject. Weird. Apparently there is no clean separation between the "block device" DMG and the volume inside. Or it's HFS being very bad when operating at capacity.
    – Tobias
    Sep 23, 2011 at 7:06

2 Answers 2

Reset to default
6

Both sparse disk images and the newer sparse bundle disk images intentionality do not reap/reclaim space until they need to. This is especially so for a sparse bundle - which is designed to reduce the network transfers when the image is stored on a network share. It certainly speeds up normal read/write operations since the system can assume compact won't happen when the files are changing. When you check things in disk utility, it perhaps sees that space could be reclaimed and does that for you. You are correct, that in normal use, it ends up with you using more space than if you simply put things on the normal file system.

You could convert your storage to a normal sparse image to get more traditional freeing of space when you delete files stored within the disk image.

Certainly read the first two paragraphs of the man page for hdiutil.

You can of course kick off a manual compact operation with:

  • hdiutil compact /path/to/sparsebundle.dmg
Improve this answer
3
  • On my boot volume I can delete files and re-use the space after emptying the trash. I don't have to fiddle with the physical drive. So why do I have to compact the underlying DMG to free up space on the volume inside? It's a bit like fragmentation: makes things slow but doesn't affect available space.
    – Tobias
    Sep 23, 2011 at 7:18
  • 2
    Like any software that humans designed with intent - that's clearly how they wanted it to work. One of the best optimizations allowed in software is to postpone or not do a task. It's clearly for performance reasons. If we could look at the code, there might also be architectural or procedural/safety reasons why this decision seemed proper when it was made (and keeps getting kept - Apple doesn't shy away from revisiting design decisions and throwing out the bad ones)
    – bmike ♦
    Sep 23, 2011 at 13:10
  • This doesn't seem to free up anywhere near the space it should. On one image I get "Reclaimed 15.3 MB out of 84.1 GB possible" where du reports the sparsebundle is taking 16GB of space, but the file system when mounted reports only 4GB is in use!
    – Michael
    Apr 17, 2015 at 5:33
0

A disk image is like a "virtual" drive i.e. a hard disk in a hard disk even if you delete a file the hard disk capacity remains constant, only the amount of available space changes, that is why your disk image remains the same size even after you delete files

Improve this answer
2
  • Further to this, I believe the Disk Utility verification process is "compacting" the space previously consumed by the deleted files, which explains why the size decreases. But Samantha Catania is correct- you shouldn't assume the disk image should decrease in size.
    – EmmEff
    Sep 22, 2011 at 15:23
  • Tobias didn't ask about this. He asked about the internal free space of the virtual drive itself, not the size of the image.
    – MiB
    Feb 22, 2019 at 9:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .