I’m in the process of setting up a Truenas server and need some help on the Pool, Vdev and Dataset configuration.
I’m using the following hardware:
HP Elitedesk 800 G4 Mini Desktop (Core i5 8500t, 16gb ram)
Sata - Intel 250gb (Boot drive)
M.2 - Adata sx8200 2tb (Exsisting drive) and Kingston KC3000 2tb (New drive)
Yes I’m mixing gen3 and 4 drives but the Elitedesk only runs at gen3 anyway.
I want to leave 200gb free for wear on the drives over time, as this will be used to backup all my photos, videos and files my priority is keeping those safe.
Down the line I may also want to start ripping my Blu Rays and stream them from the server, but might spin up another pool for that so my backup drives aren’t being hammered.
After everything is setup, I plan to offsite backup to a relatives who has a nas setup already.
What I need help with is the leaving 200gb free for wear levelling.
I currently have a couple of 250gb drives in there for testing, but when I go through the process of setting up the pool, Vdev and dataset I can’t change the size, it uses the whole drive.
Any other tips for making this a bullet proof setup are welcomed as I’ve only dabbled in Truenas before nothing long term.
I don’t think you can do this through the TrueNAS UI as it wants the entire disk.
The normal ZFS-way to limit disk space is to create a smaller Primary partition than the disk. Then, add the disk with the partition specifief instead of the whole disk, like:
sudo zpool add tank /dev/sdXp1
Warning that TrueNAS may not properly detect, monitor, nor backup/sync properly with such a setup - especially if a disk failure occurs as the UI may only be coded for raw disk values, not partitions.
From my 5 year experience of TrueNAS, it’s not worth the risk to go outside of the WebUI if you want upgradability.
Backup on SSDs? In this economy?
On a serious note though, probably not worth it. You can simply set a 80% quota and get the same result. Or use OP of some drive tools, so that the SSD itself reports that to ZFS. Either way, not worth bothering IMHO.
Wear on SSDs is no longer really a thing, unless you use a disk that is grossly the wrong tool for the task.
Do it manually with zfs CLI commands.
Bullet proof is having RAIDZ2 or mirrors and a tested and monitored, working backup, or even better a DRP on real paper. Not worring about SSD wear
I agree the excessieve wear issue for ssd’s is not so bad but it does depend on setup
As the most damaging way to uses ZFS on consumer ssd’s is as a slog special device
When setting up a group of consumer SSD’s in ZFS arrays with raidz variants.
ssd’s will run out of write cache in minus and be stuck it’s slow mode tlc/qlc write mode.
The cache won’t regenerate either as parity operation will keep hitting the ssd allowing it no time regenerate.
Buring up it’s life as no trim and wear level operations can be completed.
Speaking from experience here, I had a ssd raidz1 which performed less then just a simple raidz1 hdd array.
Zmirror and striped zmirros will have no issues at all and give the a massive read boosts as stuff in arc cache .
Setting them as a mirror for special metadata is probably the best use of the ssd’s.
Non-issue. You would need faster than a single 50Gbps network link to saturate a single KC3000. Once the KC3000’s SLC write cache is exhausted you would still need to push faster than 12.5Gbit network transfers to notice a slowdown. There is some overhead from TrueNAS and ZFS so even that would be a challenge if you had a sufficiently large and fast device to perform those sustained transfers.
The TrueNAS middleware generally doesn’t like it, when you bypass it with CLI commands, so you have to be very careful about what you are doing.
I would say there is a place to be concerned about SSD wear, but the remedy isn’t to monkey around with the partition table, but to ensure that the recordsizes in your datasets and/or zvols are properly set and consider both the physical setup of the SSDs as well as your use-case for that particular dataset/ZVOL in order to avoid write-amplification. Unfortunately you cannot specify ashift in the TrueNAS UI, but the default value of 12 (=4K minimum block size) should match most SSDs. The exceptions might be some large-capacity datacenter SSDs or some super-cheap SSDs that use a higher minimum block size in order to be able to work with a smaller mapping table between the logical blocks and the actual memory location for that block.
And as a side note to the OP: I hope you’re planning to install TrueNAS Community Edition and NOT TrueNAS Core. The latter has been essentially end-of-life for a while now.
