http://qs321.pair.com?node_id=680602


in reply to Re^4: (OT) Fixing OSX's biggest weakness as a dev platform
in thread (OT) Fixing OSX's biggest weakness as a dev platform

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.

<radiant.matrix>
Ramblings and references
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet