It seems that every news site speculates about the reasons for new leight weight Snow Leopard. I will list some:

1. No more PPC Code

All applications in Snow Leopard come as Universal Binaries. So does the kernel. Even if the “No more PPC code” rumor was true, it wouldn’t save enough to make Mail.app lose around 68% of 287MB. The Universal Binary only is 9.9MB in size. So even if the PPC code was 90%, it wouldn’t be enough to explain losing 196MB.

2. The “unneeded” language files are missing.

No, Snow Leopard still has all language files in their place.

3. Smaller Binaries.

Nothing has changed here. In fact, some apps have even bigger file sizes of the executable than before.

So, what has changed then? When you look in Mail.app you see that language files use up most of the disc space. Inside the language folder (e.g. “German.lproj”) are a lot of .nib files (the extension of Interface Builder). Inside normally are two files. One is a very small “keyedobjects.nib” and the other is very big “designable.nib” file.

When you open the Mail.app folder with “Show Package Contents”, navigating through the resources and open then a .nib file with Interface Builder you see everything the developer did when designing the application’s GUI. But all that changed with Snow Leopard. Now the “designable.nib” is gone. It seems like it had no reason other than to give hackers a chance to mess with the application’s UI design.

Today I wanted to move my Tiger FileVault Sparse Image into the Leopard testbuild (9A321). I really liked the way FileVault worked, saving everything in a crypto-image. It was really easy to back up and you were always sure that you backed up all the resource files etc.
In Leopard however, your crypto home is not stored in a sparse image anymore. It is now stored in a folder called foo.sparsebundle which has the following structure:

1> ls -la
total 24
drwx------@ 3 foo  foo   204 Dec 20 19:10 .
dr-x------  3 foo  foo   102 Dec 20 19:13 ..
-rw-------  1 foo  foo   510 Dec 20 19:10 Info.bckup
-rw-------  1 foo  foo   510 Dec 20 19:10 Info.plist
drwx------  2 foo  foo   204 Dec 20 19:33 bands
-rw-------  1 foo  foo  1276 Dec 20 19:10 token

The content seems to be in the bands folder. So this is what’s inside:

1> ls -la
total 746800
drwx------  2 foo  foo        204 Dec 20 19:33 .
drwx------@ 3 foo  foo        204 Dec 20 19:10 ..
-rw-------  1 foo  foo   90267648 Dec 20 19:44 0
-rw-------  1 foo  foo   91848704 Dec 20 19:11 80b
-rw-------  1 foo  foo   79454208 Dec 20 19:43 d
-rw-------  1 foo  foo  120791040 Dec 20 19:40 e

My impression was that freeing up unused space was much faster.

Here the content of the Info.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DT
Ds/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>CFBundleInfoDictionaryVersion</key>
        <string>6.0</string>
        <key>band-size</key>
        <integer>134217728</integer>
        <key>bundle-backingstore-version</key>
        <integer>1</integer>
        <key>diskimage-bundle-type</key>
        <string>com.apple.diskimage.sparsebundle</string>
        <key>size</key>
        <integer>276446150656</integer>
</dict>
</plist>

The key management data seems to be in the token. But I will not post that little piece of information! ;)

It turns out that you can “mount” the sparsebundles just like the sparsimages.

foo

Ok, now it is official: Mac OS X Leopard (Build 9a321) features support for ZFS. The rumors were true, you can create disk images with a ZFS filesystem, well at least in theory, because Build 9a321 is far away from being stable. The DiskUtility itself crashes again and again. Trying to create an actual ZFS image produces kernel panics. There is no pool support to create stripes, mirrors or even RaidZ in DiskUtility yet.

It seems that all the other rumor sites stopped right there, which is why we had to set up this website to show you how well ZFS is already implemented. We show you what works and what doesn’t. After reading you will know what the deal is, with ZFS and the upcoming Mac OS.

What most people are missing is the existance of command-line tools. The big news is, with Build 9a321, there is not only a ZFS.kext kernel extension, but there are also a bunch of command-line tools to manage your ZFS filesystems (as you will see as you read along). With these tools it is possible to create stripes, mirrors and RaidZ with ZFS!

I played around to find out how well ZFS is already implemented in 10.5. Here is what I did:

First, I simply added two SATA-disks with the following command-line: (I’m using files as disks now, because its much faster to play with.)

1> sudo zpool create tank mirror /Users/themachacker/test1 /Users/themachacker/test2

and boom – theres a zpool with 200MB (this is the size of the pool, not the usable size for filesystems in it)

1> sudo zpool status
pool: tank
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror ONLINE 0 0 0
/Users/themachacker/test1 ONLINE 0 0 0
/Users/themachacker/test2 ONLINE 0 0 0

errors: No known data errors

1> sudo zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
tank 95.5M 90K 95.4M 0% ONLINE -

Now we are enabling compression:

1> sudo zfs set compression=on tank
1> sudo zfs get all
NAME PROPERTY VALUE SOURCE
tank type filesystem -
tank creation Tue Dec 19 2:49 2006 -
tank used 87K -
tank available 63.4M -
tank referenced 24.5K -
tank compressratio 1.00x -
Bus error

Oops… we ran into a bug here, but the OS still is running.

Then I copied the sources of postgresql into it to test the compression ratio.

1> sudo zfs get all
NAME PROPERTY VALUE SOURCE
tank type filesystem -
tank creation Tue Dec 19 2:49 2006 -
tank used 54.3M -
tank available 9.21M -
tank referenced 54.1M -
tank compressratio 1.88x -
Bus error

1> du -sk postgresql-8.2.0
102008 postgresql-8.2.0

Originally the folder was about 100MB. With ZFS and compression it only uses 54M.

The fun thing is: you can turn compression on and off as you wish – all the time, even while the copy process is still running. The same applies for the checksum algorithm you want to use (fletcher2, fletcher4 or sha256).

Now I will delete one part of the mirror and create an empty one:

1> rm test2
1> mkfile 100m test2

how does it look now?

1> sudo zpool status
pool: tank
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror ONLINE 0 0 0
/Users/themachackers/test1 ONLINE 0 0 0
/Users/themachackers/test2 ONLINE 0 0 0

errors: No known data errors

ZFS has not detected anything. But you can check your pool with:

1> sudo zpool scrub tank
1> sudo zpool status
pool: tank
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://www.sun.com/msg/ZFS-8000-9P
scrub: scrub completed with 0 errors on Tue Dec 19 03:04:12 2006
config:

NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror ONLINE 0 0 0
/Users/themachackers/test1 ONLINE 0 0 0
/Users/themachackers/test2 ONLINE 0 0 5.67K

errors: No known data errors

After the scrub it found out that one half is missing. Other Raid0 implementations would copy the whole disk again – not ZFS. It knows, which parts are used and and only copies these. That’s the improvement over solutions like LVM. On big disks you would watch the progress, in our case it already reports that scrub has completed.

So I do what it says:

1> sudo zpool clear tank
1> sudo zpool status
pool: tank
state: ONLINE
scrub: scrub completed with 0 errors on Tue Dec 19 03:04:12 2006
config:

NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
mirror ONLINE 0 0 0
/Users/themachackers/test1 ONLINE 0 0 0
/Users/themachackers/test2 ONLINE 0 0 0

errors: No known data errors

Everything is fine again – what now? I think we should make our pool bigger. We buy bigger disks, in our case two new bigger files with 200MB each. You can then replace the older smaller disk. You could also make them mirrors and add them to the pool. But I want to replace the old ones to give them away:

1> sudo zpool replace tank /Users/themachackers/test1 /Users/themachackers/test3
1> sudo zpool replace tank /Users/themachackers/test2 /Users/themachackers/test4

So, what does it say now?

1> sudo zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
tank 196M 54.4M 141M 27% ONLINE -

But we are also interested in the usable size:

1> sudo zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 54.3M 109M 54.1M /tank

I made my old drives unused – which is exactly what I wanted. Simply think that your small tower can’t handle more than two drives.

To see what happened to your zpool you can look at the history of the commands:

1> sudo zpool history tank
History for 'tank':
2006-12-19.02:49:12 zpool create tank mirror /Users/themachackers/test1 /Users/themachackers/test2
2006-12-19.02:55:37 zfs set compression=on tank
2006-12-19.03:04:11 zpool scrub tank
2006-12-19.03:08:59 zpool clear tank
2006-12-19.03:12:24 zpool replace tank /Users/themachackers/test1 /Users/themachackers/test3
2006-12-19.03:12:39 zpool replace tank /Users/themachackers/test2 /Users/themachackers/test4

Since this feature came to open solaris only some weeks ago you can see that Apple is not very far behind with their code. It also supports RaidZ2 (the RaidZ version which supports double parity). You can see that with the following command:

1> sudo zpool upgrade -v
This system is currently running ZFS version 3.
The following versions are suppored:

VER DESCRIPTION
— ——————————————————–
1 Initial ZFS version
2 Ditto blocks (replicated metadata)
3 Hot spares and double parity RAID-Z

For more information on a particular version, including supported releases, see:

http://www.opensolaris.org/os/community/zfs/version/N

Where ‘N’ is the version number.

Since I’m testing this on a nice MBP C2D I don’t know if it also runs on PPC. But it looks like it does according to this:

1> file /System/Library/Extensions/zfs.kext/Contents/MacOS/zfs
/System/Library/Extensions/zfs.kext/Contents/MacOS/zfs: Mach-O universal binary with 2 architectures
/System/Library/Extensions/zfs.kext/Contents/MacOS/zfs (for architecture i386): Mach-O object i386
/System/Library/Extensions/zfs.kext/Contents/MacOS/zfs (for architecture ppc): Mach-O object ppc

Ok, that’s enough for tonight. But there is alot more to expore like: snapshots, clones and other cool features you don’t see in the usual filesystems.