Comments on: To SLOG or not to SLOG: How to best configure your ZFS Intent Log

By: Joon Lee

Joon Lee — Mon, 27 Apr 2020 23:08:56 +0000

In reply to Vlad. All new writes go to the in-RAM Adaptive Replacement Cache (ARC) which has a sophisticated retention policy. So yes, that client should read from RAM shortly after writing. The SLOG is technically a log in the database sense because its writes are guaranteed to be on persistent storage, but the effect is that of a flash-memory based cache.

By: Vlad

Vlad — Thu, 16 Apr 2020 16:29:06 +0000

Does ZFS cache recent writes at all?
In other words, if a client does a write and then a read to the same block (and no caching at the client, whoever it might be), am I guaranteed to go to the storage array?
Some of the answers here make it clear that the SLOG is not a cache at all.
I realize that this is an old discussion, it may not be the best place to post this question.
Thanks!

By: David LeBlanc

David LeBlanc — Thu, 19 Oct 2017 18:09:33 +0000

In reply to Eman.

The SLOG is never read from unless there is a failure (power or crash). The purpose of a SLOG is to keep the IO transactions in non-volatile space until the transactions have been committed to the pool’s dataset. When the transactions are committed to disk they are read from the transaction group (TXG) stored in RAM. So, essentially, the SLOG is just a backup device in the event that the TXG is lost due to power failure or crash. Looking at the Disk IO in the reporting section of FreeNAS will illustrate that your SLOG device is only being written to.
Mirroring the SLOG would only prevent your SLOG vdev from being accessible if one of the SLOG devices fail. In the event that the SLOG completely fails (single drive or both in a mirror), the ZIL will be written out to the pool, rather than the no longer accessible SLOG device. You will not see any performance improvement from a mirrored SLOG under normal conditions.
A SLOG device can be striped though. This will increase performance. However, with each additional drive, you increase the chance of the SLOG failing over time. Your choices would be to add a stripe of mirrored SLOGs or to invest in a fast NVMe and replace SSDs. It depends on budget and drive bay availability.

By: Eman

Eman — Wed, 23 Aug 2017 01:29:33 +0000

In reply to Collin C. MacMilla.

“Wouldn’t a mirror only improve a read from disk that never really happens?”
The cached data is written out to the pool in a certain intervale, meaning it needs to be read from the SLOG when it’s written out to the pool…

By: Manny Lakis

Manny Lakis — Fri, 16 Dec 2016 14:21:38 +0000

Great article, If we build and all SSD RAID-10 pool from MLC drives, would we benefit by installing a dedicated SLC SSD based ZIL drive – application is VMWare with NFS pools? This would reduce the wear on the MLC drives by not writing the DATA twice I assume, not sure though if this would provide any visible performance improvement ?

By: Mark Vonfange

Mark Vonfange — Tue, 17 May 2016 18:46:30 +0000

In reply to Collin C. MacMilla. Thanks for your comment, Collin. We've looked into things and updated that section to better explain how multiple SLOG devices can improve performance and guard against performance degradation.

By: Collin C. MacMilla

Collin C. MacMilla — Sat, 05 Mar 2016 23:36:14 +0000

“OpenZFS allows for the SLOG to be mirrored, which can improve your ZIL performance compared to a single SLOG.”
How does mirroring the ZLOG increase ZIL performance over non-mirrored ZLOG? Doesn’t the commit to disk (the “second write”) happen from ARC? Wouldn’t a mirror only improve a read from disk that never really happens?
It would seem that two or more ZLOG disk groups would improve ZLOG write performance since parallelism would be in favor of the write.