Can anyone tell me how many VDEVs I got here?? I, for one, read four.
Interestingly, this is the tally that one gets from creating a stripe pool in both(!!) of these scenarios:
Surely there must be something wrong with this picture, right? To my mind, the latter should show a picture with only one VDEV made out of 4 striped disks, right?
Am I the only one that’s puzzled about this?
Is this corroborated with zpool status NextCloud ?
There is no such thing as a striped VDEV, its is 4 separate VDEVs that behave like a stripe.
Again, you obtain the picture posted in the OP after creating a pool in this scenario:
The GUI is likely trying to fit the Stripe concept into a web page designed for redundant vDevs, like RAID-Zx or Mirrors. Perhaps we need to suggest a better handling of Stripe pool creation in the “Feature Requests” forum section.
Using 4 storage devices, (NVMe in your case), increases the risk of loosing the entire pool when a single storage device fails. Thus, Striped pools are discouraged.
That said, Striped pools have their uses. I use one on a miniature PC used for media services, (not using TrueNAS). It has 2 storage devices, a 1TByte mSATA SSD and a 2.5" HDD, which I use a small part for a Mirrored OS pool. The rest goes into a Striped media pool. I simply have good backups WHEN I loose a file, (which I have about several dozen times over the last 9 or so years).
That is a nice feature of ZFS, when you do loose a disk block on a non-redundant pool, you only need to restore the affected file(s).
Still curious how the command zpool status NextCloud would display it, compared to the GUI.
admin@nas1[~]$ zpool status NextCloud
zsh: command not found: zpool
My NAS is headless, hence at this point in time the only way I can run this command is from within the NAS GUI–which is what you see above.
Thanks. Looks like the TrueNAS devs need to be informed about this GUI inconsistency: the “stripe” scenario needs to be handled somewhat separately. I will attempt to do that in the days to come.
As for striped drives topology, I was actually thinking of just buying a huge external HDD, and doing data backup once a week. It appears that one has to do that regardless of the topology one uses, no matter how redundant and sophisticated.
That has got to be one of the most annoying things about SCALE.
Put sudo in front of the command.
To always be forced to use sudo or run commands with root privileges makes no sense in the context of zfs and zpool.
Not all commands or subcommands are destructive.
I can run zfs list on my Linux box, without requiring sudo or the root user.
The same is true for any zfs or zpool command. Guess what? If it requires root privileges, it will tell you.
I would rather a command fail because I do not have sufficient privileges, than to be forced to always use sudo or root to use a tool.
Is this the case when you have allowed sudo commands?
Or simply put /sbin and /usr/sbin in the admin user’s path. This is standard Unix behaviour since like forever. At least since the “grand unification” of Solaris 2 aka SysV R4.
I’ve created a feature request for making /sbin/ and /usr/sbin/ part of the default PATH for new users: