FreeBSD or Linux – A Choice Without OS Wars
Uncover the key differences between FreeBSD and Linux as we break down their features and use cases, helping users make well-informed decisions based on their specific requirements.
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.
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.
Did you know?
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:
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:
Did you know?
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:
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.
You might also be interested in
At Klara, we have an entire team dedicated to helping you with your FreeBSD projects. Whether you’re planning a FreeBSD project, or are in the middle of one and need a bit of extra insight, we’re here to help!
Uncover the key differences between FreeBSD and Linux as we break down their features and use cases, helping users make well-informed decisions based on their specific requirements.
DTraceis a powerful tool for system administrators to diagnosis system issues without unduly impacting performance. DTrace became part of FreeBSD with the release of FreeBSD 7.1 in 2009—two years before Oracle began porting DTrace, and nine years before Oracle eventually solved the inherent CDDL vs GPL license conflict.
Pkgng became FreeBSD’s official package manager in FreeBSD 10 in 2014. Applications can be easily installed from either pkg—a system managing precompiled binary packages—or the ports tree, which automates building and installation of packages directly from their source code.
Pingback: Valuable News – 2022/05/23 | 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗
Pingback: Valuable News – 2022/09/26 | 𝚟𝚎𝚛𝚖𝚊𝚍𝚎𝚗