New video from TechnoTim - some comments


Powered by Neutrality
Jan 1, 2016
So I look at YouTube sometimes and I get recommended things about TrueNAS and generally from some folks that I watch a bit.

TechnoTim is one of those folks and he made a video about TrueNAS, so I guess that put it high on my list of recommended videos.

I watched it. I had high hopes for what it might do to help people understand how to get good performance and it sort-of does some of that, but I feel compelled to call out several key errors in understanding about ZFS that came up during the video:

If you watched that video, be sure to read the below to not be confused about those things.

I'll go by concept:

ZFS Intent Log (ZIL) is something that every ZFS pool has.

Separate LOG (SLOG) is used (if a disk or disks are provided to the pool for it) as the ZIL (not in addition to it as shown in the video).

Writes go to RAM and the ZIL and are then flushed from RAM to the pool disks (never from the ZIL/SLOG itself unless recovery is invoked due to some kind of loss).

This Ars Technica article covers it well on page 3:

You don't really "need" to mirror SLOG as it's already a backup and is not used except in the cases where you would lose data still in RAM when the system can't keep that data (power cut or whatever else).

What is recommended is a very fast SLOG with Power Loss Protection (PLP) ... usually an Intel Optane. (full reading here:

SLOG can help to smooth out performance peaks on a busy system, but it's only ever going to deal with reducing the write penalty of sync writes, never "caching" writes as such (that can't be done for sync writes)... it's only "protecting" those writes which would otherwise be left "hanging" only in RAM while waiting for the next transaction group write.

I really don't like the implication of the wording in the video that the writes in SLOG ("can later be written out to disk"... of course it's from RAM, not SLOG almost all the time, but my point is that it's not really keeping it there very long)... Transaction groups go to disk every 5 seconds and the most that will be held in memory is 3 transaction groups... 1 "new" one as needed to get ready to replace the "current" one, the "current" one where writes are going until it's closed and the "last" one, currently being written out to disk. (sense and logic says that at absolute most, that's 15 seconds of writing you need to cover... realistically just over 10... let's say 100Gbit/s... 12.5GB/s... x15 = 187GB... if you can saturate a 100Gbit network)

Also a good reference in general for understanding SLOG:

As already pointed out in the video comments by @LawrenceSystems ARC tweaking isn't needed in Dragonfish as memory behavior is "fixed" to be like CORE in that version (and presumably subsequent ones).

Level 2 Adaptive Replacement Cache can be useful for some people, but only in limited circumstances.

You should really have 64GB of RAM before you consider using it.

You should see in arc_summary that you are getting a lot of misses/evictions and that's hurting your read speeds for files already read multiple times (more than twice)... implying that your "working set" (files you use for regular activities) is bigger than ARC.

There are improvements to ARC coming:

And you can set some (or all) datasets to store only metadata in L2ARC to get the benefits to file listing on large directory structures, particularly to help with things like rsyncs of large structures:
and for interest:

I get the impression that Tim has not quite understood that snapshots aren't the data...

A snapshot is a copy of the block allocation at a certain point in time which freezes all referred blocks from deletion in order to be able to present that "snapshot" or dataset/ZVOL/pool as it stood at that moment in time until the snapshot is released (destroyed).

That means that a snapshot is literally never a "backup" as it includes (almost always) the blocks themselves holding the files (and maybe some that were deleted) in the spot where they were at that moment... if that "original" is lost, the snapshot can't help.

"Copying" a snapshot is really just reading out the blocks as they were at the time that snapshot was taken, so this can be very useful for the creation of a backup (which it's great to not have files in the middle of being changed while you do) and it can also be great for quickly getting at copies of files deleted since the snapshot(s) were taken.

While mirrors are great at doing performance (when the pool was created with all member VDEVs present), if additional VDEVs are added to create more space in the pool, there's no automatic process to re-distribute (referred to as rebalance) the data evenly across all the VDEVs including the new one.

What this means is that the new VDEV will often be chosen as the location of new blocks ahead of the more full existing VDEVs, potentially reducing your IOPS.

You can do nothing and not care about it if you're just storing files/media that don't need the IOPS, but if you're doing VMs/block storage, you need those IOPS to continue to go well and/or even improve now you have an additional VDEV worth of IOPS...

Using a rebalancing script like this one: may help with that, or you can just backup, recreate your pool and restore the data to have it balanced.

Finishing notes
Overall, I don't want this to come across as a "panning" of the video... not enough of us do those kind of things that would make it easier for new folks to get into the technology and get a setup that works for them.

I applaud the effort and intent of the video, but it would be great if it didn't result in the ~65K viewers (at time of writing this) coming out with the misguided ideas about how ZFS works and getting into issues where they think it's not what they signed up for.

I like Tim's approach to his lab and technology in general and he covers a lot of interesting subjects in a very watchable and well-resourced way. I hope he might eventually see this and revise (or create an updated version of) his video.
Last edited:


May 17, 2014
Sometimes I think educational videos, (which some youtube videos attempt or claim to be), should be recorded in sections, (or modular). For example, if one section was factually in-correct, (as you noted), then re-record such a section and re-edit the main video. This would help improve the content, though perhaps not push prior viewers to re-watch it.


Jun 14, 2017
As a content creator we all strive for accuracy but being perfect all the time is hard work and this is not even just a commentary on creating video content, but also the information that is found in both blogs and forums. I will likely be making a new TrueNAS video once Dragonfish comes out I hope I get it right. :)


May 17, 2014
As a content creator we all strive for accuracy but being perfect all the time is hard work and this is not even just a commentary on creating video content, but also the information that is found in both blogs and forums. I will likely be making a new TrueNAS video once Dragonfish comes out I hope I get it right. :)
If a video content creator listens to calm, polite feedback that gives specific instances of in-accurate information, and then updates the video, that is the best of both worlds. First, making the information easier for the masses, (because some people learn better by example and someone teaching the subject). And second, improving for the future.

Some people, (whether it's in a text blog or full on video), only let the comments speak to the faults. For entertainment videos, (like a certain West Coast Canadian tech vlogger :smile:, then it's fine for me that their are some odd / in-accurate details and information.

Now for a text blog, it is different. First, it is easier to edit text to update the information. Second, it may be possible to "pin" a comment that has corrections. Thus, the blogger can "pin" the comment with corrections, reply to the comment saying, "yep, your right, fixing the blog". And then fix the blog. Perhaps 5 minutes, (not including any research that may be needed for verification of the update).

Unfortunately, nobody, (okay, nobody = less than 100), reads my blog, so I don't know if I've put in mistakes. I have edited some for English syntax issues, and re-published. But, most of it is opinions anyway;
PS: Their is some humor in some of the posts, so don't take that too seriously.
Last edited: