Using SnapRAID laid on top of four single-disk ZFS pools. (ZFS chosen for snapshot capability).
ZFS volumes z1, z2, z3, and z4 are mounted under /z
The pool directory on each volume is z
z1, z2, z3 are data, z4 is parity
smartctl is configured to point to the associated storage devices
this is a multipath configuration, so the smartctl entries point to one of the paths to that disk
Config:
content /z/z1/snapraid1.content
content /z/z2/snapraid2.content
content /z/z3/snapraid3.content
content /z/z4/snapraidp.content
data d1 /z/z1/z/
data d2 /z/z2/z/
data d3 /z/z3/z/
parity /z/z4/snapraid.parity
smartctl d1 -d sat /dev/sdc
smartctl d2 -d sat /dev/sdd
smartctl d3 -d sat /dev/sde
smartctl parity -d sat /dev/sdf
Even with smartctl devices manually configured, smart operations fail:
# snapraid smart
Failed to dereference device '0:62'.
Smart is unsupported in this platform.
...so these ZFS volumes do appear to have UUIDs, but SnapRAID is not discovering them.
Is there a way so correct the cause of this warning or disable the warning if nothing can be done to correct it?
Last edit: Allyn Malventano 2020-05-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am aware of the UUID note in the FAQ, however UUID's appear to be easily obtained for ZFS volumes, so my recommendation would be to either add the ZFS volume UUID capability or to enable the ability to bypass the warning (via config) for those using volumes without UUID support.
Separately, I suspected that the inability to obrain SMART data might be connected to this UUID issue, which is why both issues were brought up together. I can have the /dev/mapper/ paths in the smartctl config entries and it still fails (but correctly works when calling smartctl directly). Those same mapper paths could easily be cross referenced to the associated disks via blkid as noted in my original post.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ZFS datasets and pools have 64 bit GUIDs which can be queried via libzfs or by popen() zfs/zpool get guid $name. The GUIDs are true UUIDs, but concatenating the pool and filesystem GUID isn't hard. A clean solution would be define a well known ZFS user property to hold the dataset UUID e.g. it.snapraid:uuid=$(uuidgen).
Does anyone know how important UUID support is for correctness and performance?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using SnapRAID laid on top of four single-disk ZFS pools. (ZFS chosen for snapshot capability).
ZFS volumes z1, z2, z3, and z4 are mounted under /z
The pool directory on each volume is z
z1, z2, z3 are data, z4 is parity
smartctl is configured to point to the associated storage devices
this is a multipath configuration, so the smartctl entries point to one of the paths to that disk
Config:
Even with smartctl devices manually configured, smart operations fail:
Log file for the above:
Unsure what the issue is as I can successfully run the folllowing command on this system:
smartctl -a -d sat /dev/sdcNote: this issue may be similar to this prior one.
For this same configuration, SnapRAID throws the following error on syncs and other operations:
blkid reports the following for these drives (E1T0?? is the multipath device alias):
...so these ZFS volumes do appear to have UUIDs, but SnapRAID is not discovering them.
Is there a way so correct the cause of this warning or disable the warning if nothing can be done to correct it?
Last edit: Allyn Malventano 2020-05-03
please check the FAQ. There is no UUID support for ZFS.
I am aware of the UUID note in the FAQ, however UUID's appear to be easily obtained for ZFS volumes, so my recommendation would be to either add the ZFS volume UUID capability or to enable the ability to bypass the warning (via config) for those using volumes without UUID support.
Separately, I suspected that the inability to obrain SMART data might be connected to this UUID issue, which is why both issues were brought up together. I can have the /dev/mapper/ paths in the smartctl config entries and it still fails (but correctly works when calling smartctl directly). Those same mapper paths could easily be cross referenced to the associated disks via blkid as noted in my original post.
ZFS datasets and pools have 64 bit GUIDs which can be queried via libzfs or by popen()
zfs/zpool get guid $name. The GUIDs are true UUIDs, but concatenating the pool and filesystem GUID isn't hard. A clean solution would be define a well known ZFS user property to hold the dataset UUID e.g.it.snapraid:uuid=$(uuidgen).Does anyone know how important UUID support is for correctness and performance?