I've recently upgraded to Unraid 7.2.0 and changed my cache pool to ZFS. I have two SSD drives in a mirror configuration.

I get really strange performance issues when items in Jdownloader start decrypting to the cache pool. My CPU jumps to really high usage on certain cores during this, and the cache drive usage often locks up, with no other application able to read or write to it. I check the Docker containers' CPU usage and use the top command, and can't see a process that's eating it up. Everything will pause for a good few minutes, and then it'll catch up. Even after the decryption has finished, the high CPU usage and writes on the cache drives will continue for another minute or so, then it'll calm back down. It seems like the decryption is causing a write queue on the cache or something? I didn't have this issue when I had a single cache drive of XFS.

If someone could please help me out and take a look at my logs to see if there's anything obvious, I'd really appreciate it.

baldrick-diagnostics-20251118-2059.zip

System info:

i9-9900k

64gb ram with current usage sitting at around 46%.

2x2tb ssds for the cache drives.

Main thing I see at a glance is you enabled conpression on the pool, so basically everything you decompress is being recompressed at the same time to be written to the drives, and that'll be very CPU intensive.

Edited November 18, 2025Nov 18 by Kilrah

Just now, Kilrah said:

Main thing I see at a glance is you enabled conpression on the pool, so basically everything you decompress is being recompressed at the same time to be written to the drives, and that'll be very CPU intensive.

I did try temporarily disabling that and trying Jdownloader again, and got the same experience. If I disable it, do I have to re-create the dataset for it to start writing that with no compression?

I haven't gone through that process but yeah the change in the unraid UI might only affect newly created sets, might need to delve into terminal to reconfigure that particular dataset to not use compression

Don't use ZFS as a cache drive as you're already dealing with read cache within ARC.
Use L2ARC else if your RAM is eaten by ZFS ARC.

Disable ARC on your cache pool, check ashift argument is correct, for NAND, it's usually 13.

zfs set primarycache=none pool -r
zfs set compression=none pool -r

If cache is NVMe:
zfs set direct=always pool -r

Edited November 18, 2025Nov 18 by gyto6

22 minutes ago, Slippin' Jimmy said:

I did try temporarily disabling that and trying Jdownloader again, and got the same experience. If I disable it, do I have to re-create the dataset for it to start writing that with no compression?

When you edit this property, it only affects newly created files. Previous shall be decompressed after using zfs rewrite -rv (P argument to preserve files birthdate shall arrives with ZFS 2.4)

Edited November 18, 2025Nov 18 by gyto6

1 minute ago, gyto6 said:

When you edit this property, it only affects newly created files. Previous shall be decompressed after using zfs rewrite -Prv

Thanks! I've run the command to turn off compression on just the one dataset I'm downloading to. I'll have a good test tomorrow and get back 😊

17 minutes ago, gyto6 said:

Don't use ZFS as a cache drive as you're already dealing with read cache within ARC.
Use L2ARC else if your RAM is eaten by ZFS ARC.

Disable ARC on your cache pool, check ashift argument is correct, for NAND, it's usually 13.

zfs set primarycache=none pool -r
zfs set compression=none pool -r

If cache is NVMe:
zfs set direct=always pool -r

Don't forget this too @Slippin' Jimmy using the -r argument makes it recursive to all your dataset. But that's weird for a cache pool to have many dataset.

Edited November 18, 2025Nov 18 by gyto6

15 hours ago, gyto6 said:

Don't forget this too @Slippin' Jimmy using the -r argument makes it recursive to all your dataset. But that's weird for a cache pool to have many dataset.

I followed the SpaceInvaderOne tutorial for setting up ZFS on the cache drive, which means I can snapshot all my individual apps within AppData and restore each one individually.

Turning off compression didn't work. But running these commands looks to have resolved the issue for the most part;

zfs set primarycache=none poolname/datasetname

zfs set sync=disabled poolname/datasetname

Everything else is running fine, so i'm just running them on the dataset that the downloads go into.

Thanks for the help all 😊

On 11/18/2025 at 10:11 PM, gyto6 said:

Don't forget this too @Slippin' Jimmy using the -r argument makes it recursive to all your dataset. But that's weird for a cache pool to have many dataset.

Spoke too soon, still having the issue. I've seen in another thread that running zpool iostat -vyl 10 1 can retrieve some useful stats.

This is the output when idle;

And this is when trying to write to it and decrypt/extract files;

Does this suggest an issue with my sdj1 drive? 5s wait write! They're both brand new SSD's, which is strange.

Edited November 22, 2025Nov 22 by Slippin' Jimmy

Finally got this sorted. It was my setups fault all along.

I have a PCIE LSI Array card. Both SSDs were plugged into there, doh. Swapping over both the SSDS straight into the motherboard sata ports has resolved the issue. Was a bottleneck with storage speed. May be useful for others with the above command to find the issue drive! 😁