The ZFS ZIL and SLOG Demystified

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


  1. Ashley Choo Tim

    I really appreciate these articles from the FreeNAS Newsletter. It’s easier to learn about the technology with the short but informative pieces. Thank you Michael for this!

  2. Greg P

    Just leaving a comment to show appreciation for Michael taking the time to write this article. Even though I am a long-time user of FreeNAS with many running systems, I always seem to learn something from these pieces. Regularly check for new articles and am excited to see each new one even though I think I have a real life.

  3. Brian

    Thank you for the excellent write up. I am a new to ZFS as of recent and have begun my own setup. I have 8 sata drives setup as my main pool and 2 SSD’s 1 set for my Freenas OS (9.10)and another set to an L2ARC. When I setup the L2ARC I was attempting to divide the drive for a portion allocated to L2ARC and another to ZIL but could not find a means to do so. I assumed it was restricted similar to how the OS installed (forced to take the entire drive). Short of adding a 3rd SSD is there a means to use both an L2ARC and ZIL on just one of my SSD’s together?

    • Joshms

      I’d highly recommend checking out our forums! There are a lot of people that may be able to pitch in and help answer your question.

    • Mike

      This is something you should never attempt outside of just for fun. This will destroy your drive in under a week. Not to mention this is a non supported configuration.

  4. wayne

    just want to be clear in my understanding, I can mirror SLOG SSD of say 64Gbps each, and this should be sufficient for both i/o performance increase, as well as protection of system failure in middle of a write?

    • Joon Lee

      Depends on the hardware and usage whether or not it will benefit from slog, best to make a forum post describing setup!

  5. Ulf

    Can the boot SSD also be the SLOG drive at the same time or do I really need to add 2 SSDs?

    • Joon Lee

      Yes, you really do need 2 SSDs.

  6. Richard Elling

    It is not really accurate to lump NFS into the always-sync camp. Starting with NFSv3, there is an async write mode. And, unsurprisingly, async write + commit, works mostly like ZFS with the difference being the scope of the commit.

  7. Truman HW

    1. Thank you … but. (No, really — thank you).

    Why not differentiate ZIL, SLOG, L2ARC ….
    explain which are synonyms or how they’re different
    example-tasks that rely on each term …

    devices with substantial vs. inconsequential performance differences.
    how to know if the SSD / Cache-device is failing
    what those consequences are.


    Where optimal CPU cost-benefit is…

    WHY the shape of transfers in the network monitor is a quarter of a circle.

    ??? SO CRAZY! What IS that? 😀 THANK YOU!

  8. Lee E

    My critique:
    Says – “What is not obvious however is that they only come into play under very specific circumstances.”
    Then proceeds to not actually explain what those very specific circumstances actually are, just that they obviously happen during async, which is most of the time by default. We even end saying that all Truenas systems come with a SLOG, which really seems to ultimately contradict the initial impression that SLOG would only be used in certain configurations and instead lead us to believe it should always be configured if SSD storage can be made available for it.

  9. audi6

    “You can mirror your SLOG devices as an additional precaution”

    I already had SSDs that have been failing silently. Result was a corrupted file system, probably because data got corrupted during SSD writes. Assuming that this will happen to my SLOG, will a mirrored SLOG help here?

  10. Eric Murach Jr

    Ok sync vs async. So Sync for SLOG. Async nomally not? But what in case Sync=Always. I’m slower now if thats that turned on right?
    I read a write-up. It touch on that SMB doesn’t have sync. So, does that mean if all your shares are Windows SMB, It always doing Async xfrs and never sync transfers? If so if Sync=Standard does that mean the in that case the SLOG is never used? But, what if you set the the Sync=always would that force it to be used in that case? I’m just running a home NAS setup for media files mostly. A big setup yes. But not doing VM and no NFS shares as yet. I what the data protection yes but does that mean I need to set Sync=always so it would use the SLOG and provide the faster slog with the lease latency. If got Base 10-T lan and SAS3.

  11. Joshua

    Cache drives will they benefit a Video Editor in a FreeNAS build or not? Its for storing my films, and audio clips


Submit a Comment

Your email address will not be published. Required fields are marked *

ESG Labs: TrueNAS Technical Report
Download Enterprise Storage Guide Button
iXsystems values privacy for all visitors. Learn more about how we use cookies and how you can control them by reading our Privacy Policy.