Macworld Forums: Disk Image vs. Sparse Disk Image vs. Sparse Bundle Disk Image - Macworld Forums

When creating a blank disk image in 10.5.2, I've noticed that there are three options for image format: Read/Write Disk Image, Sparse Disk Image and Sparse Bundle Disk Image.

I know what a disk image is and have used the regular read/write disk image on several occasions, but I'm curious to know more about the sparse alternatives and what they are used for.

What is a Sparse Disk Image and what is a Sparse Bundle Disk Image?

thanks

A sparse disk image is an automatically expanding disk image. In other words, you can create a 50 gigabyte sparse disk image, yet only put 5 megs inside it. The disk image will only take up five megs of space on your harddisk, but will be capable of storing up to 50 gigs of data should you choose to add it. Note that it auto-expands but does not auto-contract. In other words, if you delete files from the image, you will not regain any free space on your harddisk (although you will on the image). Disk Utility can be used to "shrink" a sparse image, reclaiming any unused space on the image.

A sparse bundle is essentially the same thing, the only difference is that while a sparse image is one giant file on your disk, a sparse bundle is actually lots of small files (8 megabytes each). They work and look the same way, but you can right-click on a sparse bundle, select "show package contents" and see the individual 8 meg "bands".

The sparse bundle was introduced with OS 10.5 in order better support Time Machine (Especially with FileVault, where the entire home directory is a sparse bundle). Previously, a backup programme would see the image as one file, and if any changes had to been made to it, it would have to recopy the entire image. With sparse bundle, it can only copy the bands that have been changed since the last backup, so the backups are much quicker. It also is likely to decrease the chance of data loss, as you could conceivably restore parts of a damaged image.

Basically, if you want a sparse image, use the sparse bundle under 10.5. Only use the sparse image if you need backwards-compatibility with earlier versions of the Mac OS.

Hello,

Would you please explain exactly how "Disk Utility can be used to "shrink" a sparse image, reclaiming any unused space on the image." ..?

Thanks
:)

It looks like I may have erred in regards to claiming that you could shrink a sparseimage/bundle with Disk Utility. That said, it's still really easy to do. Just fire up Terminal and enter the following

hdiutil compact /path_to/yourimage.sparseimage

Or just hdiutil compact, then add a space and drag the image into the Terminal window to complete the path.

Great explanation, Typhoon14.

Is there a significant difference in access speed, reliability, or other factor between the three image types when using encryption? In other words, other than for backward compatibility, is there any reason not to use a Sparse Bundle Disk Image?
I use encrypted disk images for personal data, and with the drive sizes available today, space efficiency is not really a priority with these file types.

There should not be, and I myself have never experienced one (I use FileVault so have had lots of experience running the entire OS using both sparseimages and sparsebundles). In fact, if anything, breaking it into bands should increase reliability (if a single bands is corrupted, you may still be able to access your other data or even restore the damaged band from a backup), and in theory not having to write all data to one enormous file could yield performance increases when working with large images (I have not noticed a difference one way or another).

Thanks

Typhoon14,

Thanks for the really great breakdown on sparse bundle images, found it with Google.

Just to expand on the idea that one could theoretically restore part of a sparse bundle by using a back up of a "band", are there any utilities out there that would actually allow this? ie, allow you to identify a bad band within an image and replace it individually? Just trying to understand how this could work in practical terms. I suppose you could do error-checking/comparison from within Terminal on a band-by-band basis but obviously that's not practical on a very large file.

I don't presently have any issues, but in the future as my data storage grows ever-more enormous I could see the ability to repair something by using a partial method would be extremely valuable.

rgds,
winglet

Typhoon14, on 20 April 2008 - 01:37 PM, said:

I found this thread using Google, wondering about a different issue (where is the password stored with encrypted sparse bundle image volumes?). However, having read your extraordinarily clear post, I'm wondering about another issue: programs such as Entourage that store all their data in one gigantic file. Does the Mac file system permit datafiles to be sparse bundles? Could Microsoft (or other developers) create data repositories that look to the end-user like ordinary datafiles, but actually exist logically as sparse bundles, so that backup programs (SuperDuper, Time Machine, etc.) could just copy the 8 MB "stripes" that are different between source and backup?

This is by now quite an old thread, so if there are no responses in a day or two, I'll create a new thread to ask the same question.

Thanks a bunch,

nephdoc, on 19 January 2010 - 05:32 AM, said:

It would certainly be possible, although not necessarily the best solution, since the bundle would have to be "mounted" at all times to be read (technically you could write code to read it directly without mounting, but that seems like more work then necessary).

It is probably better for developers to do one of two things:

1. Large single data files should be avoided when at all possible. In addition to the backup issues, reliability becomes a factor. Microsoft's Outlook and Entourage stores are infamous for their habit of becoming spontaneously corrupt, taking all your mail with them. Apple Mail, by comparison, stores its data in a normal tree of folders with each message as an individual file. This avoids all backup issues, and means that while a message may be corrupted, it will not effect your ability to access the rest of your mail.

2. When a single file is necessary, the developers should arrange to have it split into chunks passed a certain size (the way many Virtual Machines split into 2 gig chunks)

This post has been edited by Typhoon14: 19 January 2010 - 09:38 AM

Typhoon14, on 19 January 2010 - 09:38 AM, said:

Agreed... in fact, I would suspect that the best solution is something similar to the document package that iPhoto uses. If you have a fairly recent version of iPhoto, (I have iPhoto '08) and glance in your "Pictures" folder, you'll find that the "iPhoto Library" is actually a "package" instead of a file or a folder. A package functions like a folder from a programming perspective, but is generally treated like a file from the end-users perspective -- except that you can also drill into that file package to see what's there by choosing "Show Package Contents" from the contextual menu. (Mind you, it is usually advisable to not change anything inside of a package, unless you're very sure you understand what you're about.) Thus, individual files within the package can be backed up without requiring that the entire package be packed up, but you don't need to mount it the way you would an image.

zarmanto, on 22 January 2010 - 05:36 AM, said:

Packages are great — the whole application model on the Mac relies on them. They are the reason you can generally install applications simply by draggin them into your applications folder. On Windows you have installers that dump the executable and a bunch of support files in a giant untidy mess in the Program Files folder, then make shortcuts to the application for you to actually access them. On the Mac the package hides the support files, giving you a single icon that serves as both the application itself and the launcher. It's just a better system.

Typhoon14, on 22 January 2010 - 10:56 AM, said:

Would that it were as simple as even that... Installers for Windows programs sometimes also drop DLLs and other support files into the system or system32 directories, within the Windows directory itself. They also sometimes dump support files into one or more subfolders under the "All Users", "Default User" and/or the current user profile... and for that matter, the user profiles are also quite the untidy mess in-ad-of-themselves!

So I guess what I'm saying is, I agree wholeheartedly with you; packages are truly a much more effective paradigm.