Calculation of SSD size for SLOG/ZIL device

Not open for further replies.


Nov 30, 2013
Can someone confirm the following calculation of SSD size for SLOG / ZIL device is correct?

-- Assumption --
HDD each can write 150MB/s
So a zpool of 4 HDD will write 600MB/s

-- Calculation --
1) The transaction group (txg) size will be 3GB
(600MB/s x 5 sec where txg by default will flush data every 5 sec)
2) The system memory size should kept no more than 24GB
(3GB x 1/8 where txg by default use up to 1/8 system's memory)
3) The SSD should be partitioned to 12GB (leave the rest of the SSD unallocated) for slog / ZIL device
(The maximum size of a log device should be approximately 1/2 the size of physical memory because that is the maximum amount of potential in-play data that can be stored)

Reference from:
(see Tangent: Dangers of overly large ZFS write cache)
(see Creating a ZFS Storage Pool With Log Devices)

Side notes:
(this post suggest the txg size and time can be changed)
(this post mention SLOG size should keep small)
(this post teach you how to partition SSD for the right SLOG size)
(Large RAM, small pool, performance example)


Inactive Account
Mar 25, 2012
None of it is theoretically wrong. But there's lots of realities. For example, any write that is 64kb or bigger and is a sync write goes straight to the pool. The whole logic for this is that the ZIL is meant to decrease I/O to the pool at inconvenient times. Not increase the throughput. In fact, if you increase the throughput of the pool by using a ZIL you could in theory make things worse. There's quite a few more, but that's the easiest example I can think of.

And I hate to break it to you but:

1. I have to leave the house, so I can't write more right now.
2. You are NOT going to be able to distill this stuff down to a forum setting. PERIOD. We keep getting people trying. We had 2 yesterday alone! Personally, I think it's getting incredibly annoyingas of late because we've had like a 1/2 dozen of these so far this year and I'm about to just start ignoring them and leaving them to fester with inaccurate info because my GAF factor is about zero. We've provided all this information and spent God-only-knows how many hours explaining things that unless someone is about to pay me for 8 hours of typing I'm not about to try and explain it "yet again".

Not even sure if when I am back home if I'll feel like responding. 3 in less than 48 hours is enough to make me give up the sport of explaining ZILs and L2ARCs.
Not open for further replies.