Re^3: (OT) Fixing OSX's biggest weakness as a dev platform

[radiantmatrix]

Disk images are great, but there are two reasons OSX doesn't "put everything else inside a DMG":

1. Performance: you're adding a layer of indirection, since the dmg is a file on the "real" filesystem, reading or writing a file to it requires altering a file on another file system. This is not very fast; and while it may be "fast enough" for some things, it won't be for others.
2. Reliability: if a disk gets a bad sector, the worst case scenario is that the data on that sector is lost. If a DMG file gets corrupted, that whole "disk" is damaged, often beyond repair.

In short, using disk images for development tasks is smart (you're keeping stuff in source control, and backups of that anyhow, right? Right?! :D), there's a lot of things it wouldn't be smart for.

[jasonk]

1. Performance: you're adding a layer of indirection, since the dmg is a file on the "real" filesystem, reading or writing a file to it requires altering a file on another file system. This is not very fast; and while it may be "fast enough" for some things, it won't be for others.

You would be hard pressed to find a scenario where this difference was even measurable. When it comes down to it they are both exactly the same thing, a series of blocks on a disk. The fact that you might have to do one extra lookup to find out where those blocks reside is fairly meaningless in the real world. There are plenty of other situations where people routinely add one (or more) levels of disk indirection on production systems (LVM and RAID for example).

2. Reliability: if a disk gets a bad sector, the worst case scenario is that the data on that sector is lost. If a DMG file gets corrupted, that whole "disk" is damaged, often beyond repair.

From the point of view of both the operating system and the data contained on the disk, there is no difference between a filesystem on a physical disk and a filesystem on a disk image. If you lose a block of data on either one, the effect is going to be identical regardless of whether it was a physical disk or not. The tools you would use to recover from losing a sector on a physical disk will work exactly the same on the disk image.

[radiantmatrix]

they are both exactly the same thing, a series of blocks on a disk. The fact that you might have to do one extra lookup to find out where those blocks reside is fairly meaningless in the real world.

That's simply not true of DMGs. It's a lot more than an extra lookup, and it's a heck of a lot more complex to mount what's essentially a (non-journaling) loopback filesystem with extra integrity features than it is to add LVM or RAID.

For user data, a DMG mounted from a local disk is going to be quite fast enough -- the difference in performance between that and a standard local volume is going to be smaller than the difference between a local volume and one mounted via AFP (or even USB). For thinks like the swap volume, temporary file space, parts of /var, etc., the overhead of the DMG driver would make a noticeable performance impact.

From the point of view of both the operating system and the data contained on the disk, there is no difference between a filesystem on a physical disk and a filesystem on a disk image.

That's simply not true. There's no raw block device with a DMG. If your underlying filesystem is damaged in such a way that the DMG integrity is compromised, the DMG becomes unmountable. Because of the lack of a block device associated with a DMG, you can't use generalized disk-recovery tools.

Now, none of that should prevent someone from using a DMG to store data -- and I never said it should. However, the performance and reliability concerns do make a compelling argument against using a DMG to store the OS's support system and kitchen sink.