Skip to content

Set up TrueNAS

BeamDisk is tested with TrueNAS. This page sets up a target with one disk for one Mac, then lists the settings that worked best in BeamDisk’s tests, with a few general ZFS ones. TrueNAS’s screens differ a little between versions; its own documentation has every option.

Copy your Mac’s initiator name from BeamDisk: at the top of Add Disk, under This Mac in the window’s sidebar, or in Settings → General.

  1. In Datasets, select your pool and add a zvol. Give it a size in whole MiB or GiB. Under its additional options (advanced options in older versions), tick Sparse for a thin-provisioned disk and set the block size to 16 KiB (see below). TrueNAS doesn’t let you change either once the zvol is saved.
  2. Go to Shares, find Block (iSCSI) Shares Targets and open its Wizard. Name the target, and choose the zvol as its device. Keep the extent’s sharing platform at its default (see below).
  3. Create a portal, or use an existing one, listening on port 3260. Set up CHAP here if you want it.
  4. Under initiators, add your Mac’s initiator name, so the target is offered to this Mac only.
  5. Save, and make sure the iSCSI service is running and set to start automatically (in System → Services).

Then add the disk in BeamDisk with the server’s address.

  • Zvol block size: 16 KiB, even where TrueNAS suggests 32 KiB, as it does for RAIDZ pools. With 32 KiB blocks, ZFS has to read part of a block before it can rewrite the rest: on a hard-drive pool in BeamDisk’s tests, random writes ran 14 to 38% slower, and 5 to 8 times slower once the blocks weren’t in the server’s memory; sequential writes ran about a fifth slower.
  • Extent sharing platform: keep the default (VMware) or Legacy OS, which give the disk 512-byte sectors. Modern OS (4 KiB sectors) is as fast, but a disk BeamDisk formats there can only be read through BeamDisk, and one formatted with 4 KiB sectors by Windows or Linux opens read-only. See File systems. The extent’s other options, such as TPC, Xen compatibility and the speed it reports, make no difference to BeamDisk.
  • A sparse (thin) zvol only takes space on the pool as it’s written, and BeamDisk gives space back when files are deleted.
  • Leave sync (standard) and logbias (latency) at their defaults. In BeamDisk’s tests, logbias=throughput made sequential writes up to 8% faster but cut random writes by 25 to 58%, which a Mac disk depends on for small files and its own bookkeeping. sync=disabled makes the server acknowledge writes that a crash or power cut can lose: use it only for disks you can lose.
  • SSD pools make the biggest difference to anything that asks for its data to be safely stored, and sustained writes ran about three times faster than on a hard-drive pool.
  • On hard-drive pools, add a SLOG. Without one, every request to store data safely waits for the drives: about 21 ms each in BeamDisk’s tests on two RAIDZ1 vdevs of hard drives, against 7 ms on a SATA SSD pool, and sequential writes topped out around 340 MB/s. A SLOG (a fast, separate log device with power-loss protection) is ZFS’s usual way to shorten that wait; it hasn’t been tested with BeamDisk yet.
  • Jumbo frames (MTU 9000), if every device on the path supports them: see Get the most from your network.

If TrueNAS runs in a VM, for jumbo frames the hypervisor’s bridge and the VM’s network card must allow MTU 9000 too, as well as TrueNAS’s own interface. Some hypervisors (Proxmox, for example) give a VM’s network card the bridge’s MTU only when the VM starts, so set the bridge first, then change the card with the VM shut down: changing it on a running TrueNAS VM can drop its default route.

TrueNAS supports the persistent reservations BeamDisk uses to give each disk to one Mac at a time. TrueNAS also tells BeamDisk that it can lose writes it has accepted if it loses power, so BeamDisk’s power-loss protection is on for its disks.