Hey there truenas community.
I messed up while creating my special metadata device and created 2 individual metadata devices instead of a mirrored group of the two disks. The output of zpool status looks like this:
root@RussNAS[~]# zpool status
pool: RussNAS
state: ONLINE
scan: scrub in progress since Sat Jul 20 05:56:20 2024
7.47T / 11.6T scanned at 12.7G/s, 196G / 11.6T issued at 332M/s
0B repaired, 1.65% done, 10:01:19 to go
config:
NAME STATE READ WRITE CKSUM
RussNAS ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
2055ecd8-a72c-4de9-8967-f24f55a1803e ONLINE 0 0 0
c4bf8996-ffd3-44f5-8189-cc12553b6e0b ONLINE 0 0 0
35f310a4-bb76-4d57-bd00-a7373532fa81 ONLINE 0 0 0
special
f28424a5-058e-479e-821b-4285f4e32400 ONLINE 0 0 0
4b18294a-758d-4a9f-9847-fa2d701a95b2 ONLINE 0 0 0
errors: No known data errors
I’m pretty new to ZFS and Truenas, and could use some guidance on how to fix this. Using the GUI when I try to offline either of the Disks I get an error saying that there are no valid replicas (which make sense because the disks aren’t in a mirror).
Unless special vdevs are handled in a special way, it should be possible to zpool remove one of the drives, if not from GUI then from CLI, and then add it back to extend the remaining drive into a mirror.
Having a backup is highly advisable… which makes “backup-destroy-restore” a straightforward option.
Oops! Possible brain fart here. We should be able to remove devices in stripes… if the pool is all mirrors. The raidz1 data vdev probably prevents any removal here.
Thanks for the response, I have about ~1.5tb already loaded that I actually care about and doesn’t change often so as a simple backup and safety measure I’ll just copy that data over to a hard drive I still have on another desktop so I don’t risk losing it.
I also have hourly, daily, and weekly snapshots going back for about 2 weeks but I’m not sure how useful those would be in the event of a destroy. I’m assuming those snapshots would also be destroyed / couldn’t be used for a restore?
If I were to use the GUI would rough steps be:
Click “Export / Disconnect”
Check “Destroy Data on This Pool”
Uncheck “Delete saved configurations from TrueNAS”
Click “Confirm Export / Disconnect”
Create new Pool from scratch with same RaidZ1 setup + correct mirrored metadata devices
Re-create my datasets, apps, etc.
Appreciate the checking of the above steps.
I also have SSH access setup, so can run CLI commands without hooking up a keyboard and monitor to the NAS / copy + paste, but obviously am more comfortable clicking buttons on the GUI.
Are you sure you need the metadata vdev? And your needs couldn’t be served by, say, metadata-only L2ARC? Because the latter would not be critical to your pool as is the former.
For the sake of future learning (and if you’re going to destroy the pool anyway), see if you can zpool remove one of the metadata devices then add it back as a mirror. Might save you a fair bit of time and would be good to know if possible. I would assume so as it should just evacuate data to the remaining device.
In your case it would be zpool remove RussNAS 4b18294a-758d-4a9f-9847-fa2d701a95b2
Continue with the backup first though, because everyone should have a backup!!!
Also agree on this point, doing it this way will remove the points of failure introduced with metadata vdevs (that is, if you need them at all?).
This is really a case of needing the OP to post their complete hardware, software and pools setups. The description is perfectly fine if this was just a TrueNAS machine to learn all the features and data doesn’t matter.
Sure thing find bellow full hardware specs, software details, and pool outputs. For the most part yes this TureNAS machine is for learning and the none of the data is “critical”.
Hardware:
CPU: Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
Motherboard: Gigabyte Z390 AORUS PRO
RAM: 128GB (4x32GB Sticks) DDR4 3600 (PC4-28800) C181.35V
Network: 10G Dual RJ45 Port PCI-E Network Card Gigaplus X540-T2 (Only one port in use)
Disks:
Hard Drives:
3x Seagate Ironwolf 12TB
Solid States:
2x Samsung SSD 850 EVO 500GB
NVME (Boot Drive):
1x Western Digital 500GB WD Blue SN570
Software:
Truenas Scale Version: Dragonfish-24.04.2
Datasets: (Lots under ix-applications / apps but censored for brevity)
NAME USED AVAIL REFER MOUNTPOINT
RussNAS 7.74T 13.9T 24.3G /mnt/RussNAS
RussNAS/apps 9.71G 13.9T 110M /mnt/RussNAS/apps
...
RussNAS/ix-applications 5.70G 4.30G 704K /mnt/RussNAS/ix-applications
...
RussNAS/media 1.28T 3.76T 1.24T /mnt/RussNAS/media
RussNAS/scripts 5.40M 9.99G 5.40M /mnt/RussNAS/scripts
RussNAS/windowsbackups 6.42T 6.40T 5.60T /mnt/RussNAS/windowsbackups
SMB Shares:
Name Path
windowsbackups /mnt/RussNAS/windowsbackups
media /mnt/RussNAS/media
scripts /mnt/RussNAS/scripts
Snapshots:
media:
2024-07-20-14-00-08-EDT - INFO - 25 hourly snapshots found for RussNAS/media
2024-07-20-14-00-10-EDT - INFO - 14 daily snapshots found for RussNAS/media
2024-07-20-14-00-10-EDT - INFO - 2 weekly snapshots found for RussNAS/media
windowsbackups:
2024-07-20-14-00-03-EDT - INFO - 25 hourly snapshots found for RussNAS/windowsbackups
2024-07-20-14-00-05-EDT - INFO - 14 daily snapshots found for RussNAS/windowsbackups
2024-07-20-14-00-06-EDT - INFO - 2 weekly snapshots found for RussNAS/windowsbackups
Apps:
App Name Catalog Status
jellyfin TrueNAS Stopped
mineos TrueNAS Stopped
nginx-proxy-manager TrueNAS Stopped
pihole TrueNAS Running
plex TrueNAS Running
tautulli TrueNAS Running
wg-easy TrueNAS Running
Pool Setup:
root@RussNAS[~]# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
RussNAS 33.6T 11.6T 22.0T - - 0% 34% 1.00x ONLINE /mnt
boot-pool 448G 5.23G 443G - - 0% 1% 1.00x ONLINE -
root@RussNAS[~]# zpool status
pool: RussNAS
state: ONLINE
scan: scrub in progress since Sat Jul 20 05:56:20 2024
11.6T / 11.6T scanned, 11.4T / 11.6T issued at 605M/s
0B repaired, 98.49% done, 00:05:03 to go
config:
NAME STATE READ WRITE CKSUM
RussNAS ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
2055ecd8-a72c-4de9-8967-f24f55a1803e ONLINE 0 0 0
c4bf8996-ffd3-44f5-8189-cc12553b6e0b ONLINE 0 0 0
35f310a4-bb76-4d57-bd00-a7373532fa81 ONLINE 0 0 0
special
f28424a5-058e-479e-821b-4285f4e32400 ONLINE 0 0 0
4b18294a-758d-4a9f-9847-fa2d701a95b2 ONLINE 0 0 0
errors: No known data errors
pool: boot-pool
state: ONLINE
status: Some supported and requested features are not enabled on the pool.
The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not support
the features. See zpool-features(7) for details.
scan: scrub repaired 0B in 00:00:04 with 0 errors on Thu Jul 18 03:45:05 2024
config:
NAME STATE READ WRITE CKSUM
boot-pool ONLINE 0 0 0
nvme0n1p3 ONLINE 0 0 0
errors: No known data errors
When I had much less RAM (32gb) I had configured the 2x 500gb SSD’s as L2ARC and noticed that there was always a significant % of my RAM free which obviously is not ideal.
My workload consists of storing 4k60fps Drone Videos, torrents, and taking windows backups using the built in windows 7 backup tool. I also run some apps.
Two problems there: first, 32 GB of RAM isn’t close to enough to make use of L2ARC; second, earlier versions of SCALE would use at most half of RAM for ARC. Dragonfish largely resolves the latter, and 128 GB of RAM is a good amount.
Just for posterity, running zpool remove for either disk returns the following error:
root@RussNAS[~]# zpool remove RussNAS f28424a5-058e-479e-821b-4285f4e32400
cannot remove f28424a5-058e-479e-821b-4285f4e32400: invalid config; all top-level vdevs must have the same sector size and not be raidz.
root@RussNAS[~]# zpool remove RussNAS 4b18294a-758d-4a9f-9847-fa2d701a95b2
cannot remove 4b18294a-758d-4a9f-9847-fa2d701a95b2: invalid config; all top-level vdevs must have the same sector size and not be raidz.
As for the future of the thread, my media has been backed up so will just kiss my windows backups goodbye and recreate the pool which isn’t the end of the world for me but a lesson learned. Thanks for all those that chimed in.
