The ZFS ZIL and SLOG Demystified

Written by Michael Dexter on .

The ZIL and SLOG are two of the most misunderstood concepts in ZFS and hopefully this will clear things up

As you surely know by now, ZFS is taking extensive measures to safeguard your data and it should be no surprise that these two buzzwords represent key data safeguards. What is not obvious however is that they only come into play under very specific circumstances.

The first thing to understand is that ZFS behaves like any other file system with regard to asynchronous and synchronous writes: When data is written to disk, it can either be buffered in RAM by the operating system’s kernel prior to being written to disk, or it can be immediately written to disk. The buffered asynchronous behavior is often used because of the perceived speed that it provides the user, while synchronous behavior is used for the integrity it guarantees. A synchronous write is only reported as successful to the application that requested it when the underlying disk has confirmed completion of it. Synchronous write behavior is determined by either the file being opened with the O_SYNC flag set by the application, or the underlying file systems being explicitly mounted in “synchronous” mode. Synchronous writes are desired for consistency-critical applications such as databases and some network protocols such as NFS but come at the cost of slower write performance. In the case of ZFS, the “sync=standard” property of a pool or dataset will provide POSIX-compatible “synchronous only if requested” write behavior while “sync=always” will force synchronous write behavior akin to a traditional file system being mounted in synchronous mode.

“Asynchronous unless requested otherwise” write behavior is taken for granted in modern computing with the caveat that buffered writes are simply lost in the case of a kernel panic or power loss. Applications and file systems vary in how they handle such interruptions and ZFS fortunately guarantees that you can only lose the few seconds worth of writes that came after the last successful transaction group. Given the choice between the performance of asynchronous writes with the integrity of synchronous writes, a compromise is achieved with the ZFS Intent Log or “ZIL”. Think of the ZIL as the streetside mailbox of a large office: it is fast to use from the postal carrier’s perspective and is secure from the office’s perspective, but the mail in the mailbox is by no means sorted for its final destinations yet. When synchronous writes are requested, the ZIL is the short-term place on disk where the data lands prior to being formally spread across the pool for long-term storage at the configured level of redundancy. There are however two special cases when the ZIL is not used despite being requested: If large blocks are used or the “logbias=throughput” property is set.

By default, the short-term ZIL storage exists on the same hard disks as the long-term pool storage at the expense of all data being written to disk twice: once to the short-term ZIL and again across the long-term pool. Because each disk can only perform one operation at a time, the performance penalty of this duplicated effort can be alleviated by sending the ZIL writes to a Separate ZFS Intent Log or “SLOG”, or simply “log”. While using a spinning hard disk as SLOG will yield performance benefits by reducing the duplicate writes to the same disks, it is a poor use of a hard drive given the small size but high frequency of the incoming data.

The optimal SLOG device is a small, flash-based device such an SSD or NVMe card, thanks to their inherent high-performance, low latency and of course persistence in case of power loss. You can mirror your SLOG devices as an additional precaution and will be surprised what speed improvements can be gained from only a few gigabytes of separate log storage. Your storage pool will have the write performance of an all-flash array with the capacity of a traditional spinning disk array. This is why we ship every spinning-disk TrueNAS system with a high-performance flash SLOG and make them a standard option on our FreeNAS Certified line.

Thank you Matthew Ahrens of the OpenZFS project for reviewing this article.

To learn more about iXsystems storage solutions, visit, call one of our consultative advisors at 1-855-GREP-4-IX or email us at

Why I Chose FreeNAS When I Started My Own Landscape Architecture Firm

Written by Michael Dexter on .

After fourteen years of working in the field of landscape architecture, I decided to start my own firm. I have always considered myself a quick learner when it comes to software programs and enjoy the challenge of learning new ones. Knowing my way around computer hardware, on the other hand, was another matter. I did not have a lot of experience in this area at first and found it much less approachable. That all changed about a year and a half before I started my own firm when I had an opportunity to help start and run a small branch of another landscape architecture firm. The main office of the firm purchased and/or built all of the computers, software and related computer equipment. They also purchased and built a server using FreeNAS software. I was given a quick 30 minute tutorial and showed how it worked and how to oversee it. Not long after, using screen sharing, I was instructed in how to set up separate volumes, how to control permissions, and how to add new users. I found the interface easy to use and soon had a much better understanding of network servers.

A year and half later, when I started my own firm, I decided to buy and set up a server right away so that it would be easy to grow the firm when the time came. Based on my experience with the FreeNAS software, I chose to go with the FreeNAS Mini, a server from iXsystems that comes with FreeNAS already installed. It came at a good price and was easy to set up. In fact, I had it up and running in just a few hours despite no real training in information technology. The machine came with a quick setup guide that was clear and easy to follow. Within no time, I had set up my volumes, users and access. It has been up and running now for eight months and I have had only one issue, which I was able to quickly resolve by calling a person recommended by iXsystems who specialized in FreeNAS software.

As a new business owner, it is nice to know that my data is stored on a secure and reliable system whereby I don’t have to worry about it and can instead spend my time focusing on growing my business.

Mary Moore Wallinger, RLA, ASLA
LandArt Studio

Announcing FreeNAS-10 ALPHA

Written by Annie Zhang on .

We are very pleased to announce the first public release of FreeNAS 10, FreeNAS-10 ALPHA!

(We are now on a CDN, so if you don’t see it in your time zone, just wait a few minutes and refresh)
Update train: FreeNAS-10-Nightlies

Important Note: The ALPHA release is still on the MASTER branch (we’ll branch to 10-STABLE when we get closer to, or at, 10-RELEASE) so in order to install the very latest ALPHA, simply go to and look for the latest date.

FreeNAS 10 ALPHA Release Notes

Welcome to the first ALPHA Release of FreeNAS 10, a major upgrade from FreeNAS 9.3 and a new chapter in the project’s history which offers a significant number of new technologies!

These technologies include, but are not limited to:

  • A new underlying OS based on FreeBSD 10.2
  • A completely new pluggable and extensible “middleware” server that mediates all access to FreeNAS and allows concurrent multi-user (and soon multi-role) access to the system.
  • A structured Command Line Interpreter with tab-completion, inline help, and high-level access to all FreeNAS functions and event information (See “cli” command)
  • Two different GUI front-ends to the new middleware: The “old-style” UI which should be familiar to anyone who has used FreeNAS 9.x, and a completely new UI based on modern web technologies and featuring far more interactive access to FreeNAS features (the new UI sub-project is more fully described here:
  • While not present in this ALPHA release, the Jail/Plugin interfaces have been completely replaced with a new combined Application Container and VM management system (utilizing the new bhyve VM hosting mechanism in FreeBSD 10). The UI for this will be surfaced in the BETA release.
  • A number of new file sharing methods, complementing the traditional NFS / SMB / iSCSI file sharing methods always offered by FreeNAS:
    • IPFS – The Inter-Planetary Filesystem ( – offering a global namespace and torrent-style file distribution method for content you choose to share with others (or vice-versa).
    • Riak CS ( – a distributed (clustering) database offering an Amazon S3-compatible Cloud storage API.
    • Swift and Gluster are NOT YET SUPPORTED in the ALPHA (but are coming)

Cumulatively speaking, the new file sharing methods allow FreeNAS to scale well beyond the role of “local file server” and into the realm of clustered and horizontally scalable storage, where the total data under management exceeds that provided by any single filer, yet can still be administered from a common point (“single pane of glass” management). That management UI is still under development and not entirely present for this ALPHA release, but will continue to evolve over the next couple of months as FreeNAS 10 heads for full release status.

Notes for installing this -ALPHA release:

  • Upgrades from FreeNAS 9.3 and earlier are not yet officially supported. Such upgrades will be a FreeNAS 10-BETA feature. That said, such upgrades might work, but we are not prepared to officially commit to that feature yet.
  • It should go without saying but we will say it anyway: This is an ALPHA release. Using it for anything other than testing and evaluation is a really bad idea and we do not recommend it for production use at all.
  • As noted, Jails / Plugins have been replaced by AppCafe in FreeNAS 10, but AppCafe has not yet been fully integrated as of this time and is lurking on a secret port (bonus points if you manage to find it). This will be fully revealed in BETA, so for ALPHA, no official jails / plugins support are available.
  • Encrypted drives / pools are not yet supported (we are redesigning this feature for FreeNAS 10). Do not even attempt to import an encrypted pool into FreeNAS 10-ALPHA.

We are greatly looking forward to your comments and feedback in order that we might improve this for the upcoming BETA.

The FreeNAS Development Team