Pools with different access frequency?

TrueNAS General
, , ,
1

Hi guys,

I’m new to the world of home servers and NAS devices. I just finished building my own home server, installed TrueNAS, and I’m preparing to set up the pools and datasets. My resources: 6 x 4TB WD Red Plus.

I’ve categorized the data I want to store into three tiers based on the nature of access:

Tier A: family photos, videos, official documents, memories, etc. → new items are added relatively rarely, and reading is even rarer (no deletions).

Tier B: media files, movies, music, etc. → this expands more frequently, and reading is also common (deletions are rare).

Tier C: torrents. Downloading and seeding a larger amount of torrents.

My plan is to have 3 pools for these three categories, each with 1 vdev of 2 x 4 TB in mirrored mode. I’m assuming that the more frequent the access, the quicker the HDD will fail. Therefore, in this setup, the most critical Tier A would hardly be accessed, extending its lifespan. Tier B would be read a bit more often, but the main point is that it would be separated from Tier C, which will be the most heavily used due to seeding. Over time, some items from Tier C may be moved to Tier B, but not all, only those that are worth it. (Regular backups will be made for categories A and B.)

I’m also considering putting a separate SSD for the “incomplete” torrent files, and once they are fully downloaded, they would be moved to Tier C (so that the heavy writes don’t burden Tier C).

My question is: what do you think about this configuration? Is it worth placing categories B and C in separate pools to ensure that seeding only stresses 2 HDDs (instead of 4)? (My goal is more about reliability than performance.)

2

I would personally have a single pool of 6x4TB RAIDZ2 - giving you 16TB of useable storage rather than the 12TB you would get using mirrors, plus improved redundancy.

IMO this setup will be perfectly adequate for all your use cases. qBittorrent should (if you set it up right) allow ZFS to cache the active seeds which should also benefit from sequential pre-fetch.

None of the use cases needs synchronous writes IMO - if a downloading torrent loses a few blocks in a power cut, the bittorrent hashing will find the error and redownload the relevant blocks anyway. So create separate datasets instead and ensure that the async setting is on.

But, you might need a reasonable amount of memory for ARC to keep holding the more commonly seeded data.

1 Like
3

@Protopia Thanks for sharing your opinion!

I have 32 Gb ECC ram in my machine. Do you think it is enough for a “moderate” seeding?

RAIDZ2? Sounds good. In this case, it can withstand the loss of two drives → more reliability. I only chose mirror in the first place, bacause I read some bad things about how resilvering in a RAIDZ array stress the other drives.

4

AFAIK, hard drives don’t wear out from being used like you propose.

I too second the raidz2 solution. Just replace a disk if it fails.

And RAID is not a backup. You should backup your important documents and photos.

Your NAS may be a backup, if it’s not the only copy.

1 Like
5

Sorry, I run QB on my laptop not my TrueNAS server.

I have no idea how much memory QB uses as an app, nor how much ARC you need. And the amount of ARC will depend on whether pre-fetch is triggered (which will depend on the torrent block size and the dataset record size I think - if pre-fetch is triggered then by the time this block has been sent to t’internet, the next block will have been pre-fetched and ready to send straight away - so ARC is less important for the torrent data. But I don’t know whether QB keeps the torrent metadata in memory but if not and it keeps reading it from disk then you will want torrent metadata kept in ARC.

My own system has only 10GB of memory i.e. 2.5GB of ARC, and yet with this limited memory ARC is 99.1% effective. But aside from needing metadata for its own housekeeping (i.e. replications) my system only does Plex streaming in the evenings (which definitely qualifies for pre-fetch) and backup writes and reading / writing the occasional relatively small files which are shared between various Windows PCs by storing them centrally on the NAS.

So I would expect 32GB to be a very good starting point - and once your system is fully populated and running as you want, you can look at the ARC stats and see if you think more memory would be useful.

P.S. You should plan for two SSDs - SATA or NVMe. One small one (>32GB or nearest you can get) as a boot drive, and a moderate one (256GB or 512GB as an apps-pool (to hold your apps and their metadata and VMs etc.)

Re Stux’s comments on backups:

  1. I use the NAS as a backup copy of personal files on my family’s PCs and mobiles.

  2. I use the NAS as a *primary copy of shared files and media, and everything but TV and films is backed up to pCloud (I bought 500GB pCloud storage for a pretty cheap 1-time payment).

So I have multiple copies of everything I cannot redownload on multiple systems.

I also use TrueNAS to replicate (i.e. backup) my SSD pool to HDD, and use Snapshots to be able to roll-back to an earlier recent date if necessary.

1 Like