TrueNAS provides storage via Pools. A pool is a bunch of raw drives gathered and managed as a set. My pools are one of these:
|single drive||no TrueNAS advantage other than health checks|
|raid1 pair||mirrored drives give normal write speeds, fast reads, single-fail redundancy, costs half of storage potential|
|raid0 pair||striped drives gives fast writes, normal reads, no redundancy, no storage cost|
|raid of multiple drives||raidz: optimization of read/write speed, redundancy, storage potential|
The three levels of raidz are:
- raidz: one drive is consumed just for parity (no data storage, ie you only get (n-1) storage total), and one drive can be lost without losing any data; fastest; very dangerous to recover from lost drive ("resilver" process is brutal on remaining drives - don't wait)
- raidz2: two drives for parity, two can be lost
- raidz3: three drives for parity, three can be lost; slowest
Every pool should have one child dataset. This is where we set the permissions, important for SAMBA access. We could have more than one child dataset, but I haven't had the need.
Dataset settings (NOTE: "Perm type Basic" is important!):
name #pool#-ds share type SMB user m group m ACL who everyone@ type Allow Perm type Basic Perm Full control Flags type Basic Flags Inherit
Share each dataset as a Samba share under:
Sharing > Windows Shares (SMB)
Use the pool name for the share name.
Use the same ACL as for the dataset.
WARNING I had to set these Auxiliary parameters in the SMB config so that symlinks would be followed.
- Services > SMB > Actions > configuration > Auxiliary Parameters:
unix extensions = no follow symlinks = yes wide links = yes
- Stop and restart SMB service
Burn in a new drive
ALWAYS do this even tho it's a PITA. Less pain than not doing it.
Regularly do SMART, scrub, resilver
Never do more than one of these at a time, and never do any of them during heavy disk usage (backups, eg).
SMART can be done weekly (not too often or it will contribute to early wear-out of SSDs).
Same for scrub.
Resilver happens when a drive issue requires the data to be rebalanced or redistributed. Buckle up for this one!
Pool speed check
CAST to SAFE: ~114MB/s write (compressed) on 60MB/s network
Do this to test raw write speed from anywhere on the LAN to the [safe] pool:
dd if=/dev/zero of=/mnt/safe/safe-dd/speedtest.data bs=4M count=10000 # on hive: 4GB transferred in ~15sec at ~2.9GB/sec, WOW # on cast: 42GB copied in 371sec at 114MB/s - that seems in line with my network speed (see below)
To test the network bandwidth limit:
# on hive iperf -s -w 2m # to run in server mode, looking for 2MB transfers # on another LAN machine iperf -c hive -w 2m -t 30s -i 1s # on cast: 1.51 GB at 477Mbits/sec aka 60MB/sec # I have a 1Gb switch, i guess that's all we get out of it?
Remove a bad pool
- Make note of which drives use the pool; likely some are bad and some are good and perhaps worth reusing elsewhere.
- Disconnect SMB connections to the pool
- Update valid shares in mh-setup-samba-shares
- Rerun mh-setup-samba-shares everywhere (eventually anyway)
- One possible easier way to get SMB disconnected from the pool is to stop SMB service in TrueNAS
- Sadly, to get through this for my splat pool, I had to remove pool, fail, restart hive, remove pool.
- Pool > (gear) > Export/disconnect
- [x] Delete configuration of shares that use this pool (to remove the associated SMB share)
- [x] Destroy data on this pool (you MUST select this or the silly thing will attempt to export the data)
Updating is baked into the UI, nice! And I have auto-updates enabled. So nice.
These guys work hard on this, to make sure releases are well tested. Watch for alerts about newly available updates. Do not update past the current release!
System > Update > [Train] (ensure you have a good one selected; on occasion, you'll want to CHANGE it to select a newer stable release!) Give the system a minute to load available updates... Press Download available updates > The modal will ask if you want to apply and restart > Say yes
That's about it!
Set up user
I set up m user (1000) and m group (1000)
Set up alert emails
Go to one of your google accounts to get an App password. It has to be an account that has 2fa turned on, bleh, so don't use email@example.com. I went with firstname.lastname@example.org.
Accounts > Users > root > edit password > email@example.com System > Email > from email > firstname.lastname@example.org, smtp.gmail.com 465 Implicit SSL, SMTP auth: (email/API password)
SOME of my shares were throwing Permission Denied errors on mv. Solutions:
- I applied permissions again, recursively, then restarted the SMB service on hive and the problem went away.
- You can also always go to the melange hive console, request a shell, and things always seem to work from there (but you're in FreeBSD world and don't have any beauty scripts like mh-move-torrent!)