drive and filesystem config for TRUENAS-MINI-3.0-XL+

[jcizzo]

Hi folks,

i'm setting up a TRUENAS-MINI-3.0-XL+ from scratch for my company.
it has 8 spinners and 2 ssd's. the ssd's are comprised of 1x~15GB and 1x~450GB drive. there's also the ~15GB dom but i don't think that has anything to do with this other ~15GB SSD.

this will be joined to our AD domain and serve as our fileserver (of course) behind the domain controller.

our company was ransomwared and we lost everything. during that time this box had a different purpose but now it's being repurposed as a file server.

the 8 spinners will be set up as a raidz2 pool. what am i supposed to use the SSD as? i figure one should be a zfs read cache and the other a slog, however we won't be needing synchronous writes, so from what i've read a slog wouldn't have much of a purpose.

Advice?

thanks!

 

[jcizzo]

just to add to my question, since we're not gonna need sync writes, should i skip the slog altogether and use a 'metadata' vdev?

while this isn't my first time setting up truenas, it IS my first time setting up in a scenario this advanced (advanced for me anyway).

thanks again!

 

[Redcoat]

With the information that you've given, it looks like your decison on no slog is the right one.

With respect to the zfs read cache question, conventional wisdom here is that you should max ram to a minimum of 64GB before even thinking about adding L2ArRC and then only if your ARC hit ratio is low from testing on actual conditions - there are lots of threads on this topic here on the forums. Also, you haven't yet told us how much RAM you have in the box.

It's probably worth a check on your HDD's also before you get up and running. Have you established/confirmed that they are CMR, and NOT SMR, drives?

Your 15GB DOM will be your boot device. I would not be driven to use the SSD's until you have a clearly established, legitimate, performance need for them. Forum members will have plenty of advice for you given opportunity to review intended duty, local support, and actual performance of your working server.

 

[Arwen]

One note, a Metadata Special vDev is best served by having the same redundancy as the main data vDevs. If you have a RAID-Z2 data vDev, which implies 2 disks worth of redundancy, a Metadata Special vDev should be a 3 way Mirror. Thus, either the data vDev or Metadata Special vDev, or both, can loose any 2 disks without data loss.

Loss of a Metadata Special vDev will damage a zpool beyond repair. That would require full restore from backups. Thus, the highly suggested configuration of the same amount of redundancy in the Metadata Special vDev, as the data vDev(s).

 

[NugentS]

Yes as others have said - do not use a metadata special.

The way I would do it is as follows:
1. Ignore the SSD's (other than the boot obviously)
2. Populate the NAS & set up backup processes etc - make sure its all working
3. Run the NAS for a few weeks of actual full time use
4. Check your arc hit rate and come back here with that value. We may be able to advise further at that point

I am curious, as others are - how much memory? Also how many users do you have?

 

[jcizzo]

it has 32 Gigs of ram.. from what you're all suggesting, it seems like i shouldn't bother incorporating the ssds in the setup. as said above, this is a TRUENAS-MINI-3.0-XL+ it was purchased, received, and set up outta the box. so whatever is in it, is what it came with. i was a bit surprised that it only has one ssd for slog (i guess), being that it's recommended all over to use mirrored ssds for it.

seems like i should just redo the pool without any ssd's.. is that what you're all suggesting?

it'll only be used for simple file storage (i guess).. in it's previous life it was used for vm and workstation backups (via veeam and urbackup). so i guess write speed was paramount when 40+ vms are being written to it. we're a very small company and it's probably complete overkill.. definitely overkill in terms of capacity..

it has a chelsio nic and maaan that thing gets HOT!

 

[NugentS]

For a SLOG failure to be a major issue - the device has to fail at the same time as the NAS enexpectedly reboots (kernal panic, power cut etc) as under a steady state the SLOG is always written to, and never read from. If it fails at other times - things slow down, but continue to work (at least in theory).

Unless you are using sync writes - which from the sounds of it you aren't then the SLOG is a waste of time. Simple file storage will be async (unless you like things running very slowly) and thus won't touch the SLOG