The main giude assumes that your illumos-gate workspace resides in a directory named /code (likely located in your rpool) and owned by your build user.

However, this is not very practical regarding further OS updates, compression, snapshots and rollbacks and a myriad other features that a dedicated ZFS dataset might give you. So it is recommended to create one instead and also link it as /code (at least for the consistency of this guide and some others that link to it):

sudo zfs create rpool/export/home/illumos-dev
sudo zfs create rpool/export/home/illumos-dev/code
sudo ln -s ./export/home/illumos-dev/code /
sudo chown -R $USER /export/home/illumos-dev

Now that you have a separate dataset, you can optimize it for space and/or access speed by setting some ZFS attributes, for example:

sudo zfs set compression=lzjb rpool/export/home/illumos-dev
sudo zfs set atime=off rpool/export/home/illumos-dev
sudo zfs set sync=disabled rpool/export/home/illumos-dev

Since this is a ZFS dataset, you can later zfs snapshot it (i.e. after successful builds) to make a zfs clone and/or to zfs rollback to some known-good state. In fact, you can (optionally) delegate the administrative rights for that to your build-user:

sudo zfs allow -l -d -u $USER \
  create,destroy,snapshot,rollback,clone,promote,rename,mount,send,receive \

Finally, one of your large space consumers would be the package repository containing the built installable binaries. You can seperate that into a standalone dataset for the same ZFS benefits of independent data lifecycle, replication or storage optimization, for example:

sudo zfs create -o atime=off -o compression=gzip-9 \
sudo chown -R $USER /export/home/illumos-dev

### NOTE: Make the symlink AFTER checking out the source:
sudo ln -s ../../packages /export/home/illumos-dev/code/illumos-gate

It is arguable whether a separate dataset for packages is at all needed (and it is relatively small compared the the build workspace directory). Well, I for one like putting stuff into different boxes  (smile)

Administrative rationales however include:

  1. When working on many bugs, people can have several "code" workspaces maintained as ZFS-clones of one golden code repo, as summarized in Working on several bugs at once
    However they can want to share the package repository between such projects, and maintain one package depot once configured.
  2. Snapshooting the package repo before and after a build to check for differences, or to do a zfs send to another machine.
    rsync may be better though (since the rebuild would likely wipe the repo and create it anew, even if made up of mostly the same contents – zfs diff would be huge, but rsync data diff would only include changes).
  3. nfs/cifs-sharing of the package repo may be easier to set up if it is a separate dataset.
  4. It can be located separately from workspace – another pool, different hardware (i.e. ramdisk/SSD for compile workspace, HDD for package repo).

main guide