#BUSTED

[@jeffreyrh]

Great stuff. I just setup my first TrueNAS and my first experience with ZFS. Still learning but this helps. Just found your channel. A walk through of setting this stuff up for maximum performance would be great!

[@LAWRENCESYSTEMS]

Excellent video especially the explaining of small writes being coalesced into part of the commit transaction.

[@stevetrevena145]

😅😅😅

[@stevetrevena145]

😅u😅😅

[@stevetrevena145]

😅u😅😅😅😅😅i

[@stevetrevena145]

😅78😅😅

[@camaycama7479]

Wow so many thanks for the awesome content!

[@kwinzman]

Easy to understand. More please!

[@eduardonobrega77]

What an incredible explanation, thank you

[@mitcHELLOworld]

Aw thank you so much! I am really glad the explanation is coming across well !! Let me know if there's anything you'd like to see next!

[@eros6182]

Wow, this was some top notch info really well explained. I have been using zfs many years and to this day this is the best explanation done in the least amount of time. Good work and thanks!

[@ArronMabrey]

Love the myth busting format to combat outdated/wrong foot gun info.

[@thibaultmol]

It's funny how I've been learning about zrs for what feels like a decade. But this the best explanation I've ever had for exactly what sync versus async means

[@michaelcorvin1129]

Thanks, super informative - as usual for 45Drives' excellent content! Really helped my noob understanding of ZFS in general, not just the "IOPs myth".

[@florian7679]

Perfect explanation. I would have liked to see in the video what the performance would have looked like with an L2ARC cache, and how and when tx_groups are written down by the different layers. ARC -> L2 -> HDD.

[@TheRealFunar]

Perfect explanation. I'm pointing people to this video anytime a ZFS performance discussion comes up.

[@jsaenzMusic]

I'm still trying to understand our sporadic but intense ZFS performance problem at work. When it happens, it brings almost all of our VMS to a screeching halt due to CPU IO wait (on the VMs) from disk latency happening on the ZFS storage back end itself. It's completely set up with tons of slog and caching disks. Even if an application is explicitly calling sync (), if you have your slogs set up, shouldn't they still return good iops? anyway, just blabbing along at this point...

[@consecratedtech]

LETS GO!!!! I love me some 45 Drive knowledge!!!! Keep it coming!!!

[@stefan5014]

Awesome informative and compact - thank you! What would also be incredibly interesting although I don’t know if it fits a mythbusting series: NVMe pool layout comparisons with the focus on iops, throughput and latency. We all know mirrors are king, but what about other layouts since ssd prices grow these days? There is not a lot of information / comparison benchmarks available on NVMe only pools - although the demand is growing. The concept of this video, including all the explanations and live screen tiling with the measurement tools is perfect.

[@meaga]

Incredible! Great explanation. Please continue the series!

[@jsaenzMusic]

Man......LOVED this explanation and it really made light bulbs go off. Is taking advantage of all the support vdev types (slog, l2arc and special) all that is necessary to prevent latency caused by large rand I/O workloads? Especially for a storage pool that is backing VM storage? Thank you as always for the videos!

[@retrogear]

Great video, thanks. Hoping you can expand a little on SLOG and L2ARC as ways to improve performance and in what situations to expect these improvements. Cheers!

[@cashy2011]

Yes, this would be great!

[@iteranq]

AMazing clear explanation! Thanx a lot!

[@mspencerl87]

Perfect! Deduplication next!

[@acomav]

Great video and explanation. Thoughts...what happens with a deeper iodepth? Any difference? How about a larger blocksize.

[@Thalamus4]

Love it - thanks.

[@shangtsung2450]

Interesting. I wonder, if the Special metadata device also helps with writes? Maybe, on a fragmented system?

[@nmihaylove]

What about logbias=throughput? Doesn't that get rid of the double write penalty?

[@nippurtech572]

Good explanation, but what about the cache, if you add an nvme (m.2 or u.2) for cache vdev? not referring to log vdev.

[@EduardoReyesDPM]

Awesome explanation

[@mitcHELLOworld]

Aw thank you so much! Super happy to hear the explanation is coming across well! If there is anything you'd be interested in us myth busting next, let us know :)

[@scottpeters1376]

Ok so this explains sync vs async as others have said. But the title is Single Drive IOPs Limitation per RAIDZ vdev? I don't feel it explained that at all. If I take 8 drives in a two disk mirror per vdev and put them in a pool that will outperform an 8 disk single RAIDZ2 in a pool every time.. no ? Just talking performance not capacity. Or am I misunderstanding what this was supposed to explain? I guess if I had to put the issue I am trying to understand into words exactly it's that adding spindles to any Raidz vdev doesn't seem to increase perfromance as I would expect with zfs async or not.

[@AndrewTa530]

I hope you all fixed your manufacturing process as I bought a 45drive server years ago and it was a total disaster. No drive caddies - supports response was to just allow the backplane connector to support the drive…..huh? Server was suppose to be fully installed and configured - drives shipped separately and nothing was configured. We paid to ship it back. #neverAgain

[@45Drives]

Hey Andrew, I’m hoping we can clear some things up for you. Our server uses a caddy-less design, meaning that 3.5” drives will fit perfectly into the server. This is an intentional feature, because it saves you from spending time screwing them in or out of a caddy. If you’re talking about 2.5” drives, we have provided caddies which we 3d print for years. We also sell servers with caddy-less 2.5” drive slots (Stornado SSD server and Storinator Hybrid SSD + HDD server). To your other point, we have always drop-shipped our drives from a vetted supplier. If we shipped the drives inside the server there would be a greater risk of damage in shipping. Instead, drives are shipped in protective packaging and come factory-sealed. Our standard process is on-site configuration from our support team. This should have been communicated to you during the sales process. We apologize if there was any confusion or miscommunication from our staff. Hope this clears some things up. Thanks!

[@doodlebroSH]

Bob Zelin in shambles.

[@mitcHELLOworld]

Gonna have to explain haha