SSD Cache Exclusively for Transmission

[MisurePidgeon]

Hey all, I've got kind of a unique question I haven't been able to find an answer to.

It has been well documented and frequently mentioned that in most cases for most consumers, money spent on an SSD to be used as a cache would be better off put into more RAM, and that a lot of people won't see much benefit. As I'm running 2.5 GB NICs and switches that run out of bandwidth well before I saturate the speed of my spinners, it sounds like that applies to me as well.

However, in my personal experience outside of TrueNAS when I just had a windows laptop and a bunch of USB hard drives connected, I noticed a marked improvement to torrent performance in Transmission when I had it download directly to an SSD, and once its complete then to move it to a slower but larger HDD (as opposed to downloading directly to the HDD).

I'm curious if there's a more elegant way to implement this in TrueNAS outside of creating a new pool with a lone SSD vdev and using mountpoints in the transmission jail creatively. Any insights would be greatly appreciated.

 

[jgreco]

I'm curious if there's a more elegant way to implement this in TrueNAS outside of creating a new pool with a lone SSD vdev and using mountpoints in the transmission jail creatively. Any insights would be greatly appreciated.

There isn't, really. On one hand, if you maintain a relatively empty pool and have lots of RAM, you can get near-SSD speeds on a HDD pool thanks to the way ZFS transaction groups cluster writes, and ARC for read cache. On the other hand, ZFS isn't actually magical, so sometimes just building the mechanism that actually does what you want is the most efficient way of getting the result you want.

 

[HoneyBadger]

Downloading to a temporary location and then moving (copying and deleting) the file to a new dataset can help by defragmenting the file during that second move, so I would look at that as a net positive that would still be beneficial even if you're using the same slow HDD on the back-end.

Disabling preallocation on your torrent client could potentially help avoid a copy-on-write scenario where a large empty record is written (that compresses to zeroes) and then gets overwritten in small pieces. There were also considerations for using a smaller recordsize for the "temporary" download dataset to avoid this, but it could potentially impact throughput especially on an SSD where you're not trying as hard to avoid the physical seek times of platter media.