In Basics of ZFS Snapshot Management, we demonstrated how snapshots and clones can be used to access data from a given point in time. In this article, we’ll learn when is the right time to use SLOGs

A common OpenZFS support question is “do I need a SLOG, and if so, which type of device should I use for the SLOG?” In order to answer that question, we need to first examine how OpenZFS handles write requests to disk.

Synchronous vs Asynchronous Writes and the ZIL

There are several moving parts when it comes to writing data to disk:

There are two types of writes: asynchronous and synchronous. An asynchronous write provides immediate confirmation when it receives a write request, even though the write is still pending and hasn’t yet been committed to disk. This frees up the application from waiting for the confirmation and can provide a performance boost for applications with non-critical writes.

A synchronous write guarantees integrity by not providing confirmation of the write until the data has actually been written to disk. This type of write is used by consistency-critical applications and protocols such as databases, VMs, and NFS.

All pending writes are stored in the ZFS write cache. This is located in RAM, which is volatile, meaning its contents are lost when the system reboots or loses power.

To maintain data integrity for synchronous writes, each pool has its own ZFS Intent Log (ZIL) residing on a small area of storage disk. Pending synchronous writes are stored in RAM and also logged in the ZIL.

ZFS is a transactional filesystem: it writes to storage using transaction groups, which are created in set intervals every 5 seconds. These groups are atomic, meaning the entire contents of a transaction group must be committed to disk before it is considered a completed write.

What happens if a failure, such as a power loss causing a system reboot, occurs? Everything in RAM, including all pending transactions and asynchronous write requests, is gone. If there was an interrupted transaction group performing a write, that transaction group is incomplete and the data on disk is now out-of-date by 5 seconds, which can be a big deal on a busy server.

However, keep in mind that pending synchronous writes are still on disk in the ZIL. On system startup, ZFS reads the ZIL and replays any pending transactions in order to commit those writes to disk. That sounds like a pretty good system: pending synchronous writes still get written and no more than 5 seconds worth of asynchronous writes are lost.

So, Why a SLOG?

Having the ZIL reside on the storage disks can result in contention: in other words, ZIL writes and reads must compete with other disk activity. This can cause some performance issues, especially on a system with a lot of small, random writes. On a busy pool limited by disk seek speeds, ZIL performance gets slower as pool activity increases.

It makes sense to offload ZIL activity to a faster media, such as an SSD or NVMe, for pools with a large amount of synchronous writes.  In ZFS, you do that by adding the log virtual device to the pool. This log device is known as the separate intent log (SLOG). If multiple devices are mirrored when the SLOG is created, writes will be load-balanced between the devices.

Before creating a SLOG, keep the following points in mind:

• the SLOG requires at least one dedicated physical device that is only used by the ZIL
• you should mirror your SLOG devices
• not every pool has to have a SLOG
• regardless of whether or not you create a SLOG, each pool still has its own ZIL; creating a SLOG just moves the ZIL from pool storage to the dedicated device
• neither the ZIL nor the SLOG make a difference with pending asynchronous writes which are always stored in volatile RAM: if you don’t have any applications that use synchronous writes, you don’t need a SLOG as it will never be used

What Type of Device Should I use for a SLOG?

When purchasing a SLOG device, you want something that is non-volatile and battery-backed. It does not need to be large as the ZIL only needs to have enough capacity to contain all the synchronous writes that have not yet been flushed from RAM to disk. Often, 16GB to 64GB is sufficient. For a busy server with a lot of writes, a general rule of thumb for calculating size is: max amount of write traffic per second x 15.

In addition, you need to balance:

• cost
• speed
• latency
• endurance

For example, a SLOG device could be a small, separate hard disk. It won’t be fast like an SSD, but it has endurance and you probably already have a stack of small disks lying around.

SSDs will provide speed, but not all SSDs are created equal and you generally get what you pay for. If you want speed, low latency, and endurance, it will cost you. Some acronyms to look for when shopping for an SSD:

• QLC/TLC: these are the cheapest types of SSD with the lowest endurance and are not recommended for SLOG use.
• MLC: this type of SSD is low-cost as it doesn’t have a supercapacitor and has limited endurance. It is considered to be consumer- rather than enterprise-grade.
• SLC: this type of SSD is more expensive, has greater write endurance, and is a good choice for heavy, enterprise write environments.
• PLP: (Power Loss Prevention). Some type of super capacitor or battery to ensure pending writes are not lost when the power is. Verify that the SSD provides this.

Putting it all Together

OpenZFS provides several mechanisms to ensure that data gets written to disk. On a busy system that utilizes synchronous writes, moving the ZIL to faster SLOG media can reduce contention and might yield a performance boost.

When purchasing a SLOG device, remember that endurance and reliability comes at a cost.

If you want to discuss if your use case would benefit from a SLOG or are undecided which SSD is right for you, we’re here to help.

Meet the author: Dru Lavigne

Dru Lavigne is a retired network and systems administrator, IT instructor, author, and international speaker. Dru is author of BSD Hacks, The Best of FreeBSD Basics, and The Definitive Guide to PC-BSD.

Read more

Like this article? Share it!

• Share on Twitter
• Share on LinkedIn
• Share via Email
• Share on Reddit