Sparing disk space with ZFS clones while setting up a developer environment for multiple users

I have got some Solaris 10 workstations which are shared by a bunch of users which daily develop their application in the native Solaris 10 OS. Every user has to be able to log in in whichever machine and use his own environment. For this reason we took the usual approach of setting up NFS remote mounting of home directories and managing user accounts in an LDAP.

The developers also use a virtualized Windows and a virtualized Debian GNU/Linux during their duties and the initial deploy of the workstations didn't take into account the viability of accessing via NFS files as big as xVM hard disks. Replicating hard disk images was an issue and saving workstations hard disk space was another: with an average 15 GB per hard disk (OS and applications fully configured), per OS, per user, the 200 GB hard disk that equips the workstations seemed insufficient.

In this case, and in all the cases where you can share at least an initial set of data, ZFS helped us solving this problem. ZFS clones are filesystems generated from a snapshot of another ZFS filesystem. Initially a clone consumes no space and, as modifications starts to be applied, it begin to diverge from the snapshot it was generated from and starts allocating space. In our case, I snapshotted the initial installation of Sun xVM VirtualBox, I created a clone per user and set the mountpoint of the ZFS filesystem into the user home directory:

# zfs snapshot virtualbox/installation/dir@initial
# zfs clone virtualbox/installation/dir@initial virtualbox/users/name-0
...
# zfs clone virtualbox/installation/dir@initial virtualbox/users/name-n
# zfs set mountpoint=/export/name-0/.VirtualBox virtualbox/users/name-0
...
# zfs set mountpoint=/export/name-n/.VirtualBox virtualbox/users/name-0

ZFS clones spared me a lot of troubles and, moreover, every user has got a dedicated filesystems for its VirtualBox with all of the advantages provided by ZFS such as snapshots, restores and backups. We used the same approach to provide a common set of low-volatility filesystems to our users such as big SVN repositories and documentation directories.