For over 15 years, when storage was the question, Solaris/Illumos was my answer.
I still prefer OmniOS Unix as its ultra minimalistic approach and the stability of Illumos ZFS is a guarantee for a troublefree system, especially when it comes to SMB ACL where Linux and SAMBA is a pain.
Now mainstream is more and more OpenZFS on Linux or Windows (nearly ready). Some newest OpenZFS features are not yet available in Illumos. This and the upcoming OpenZFS on Windows led to my decision to additionally support OpenZFS (any OS, additionally Storage Spaces on Windows) with my napp-it web-gui.
Porting ZFS management was the easier part. ACL management was not so easy with Posix ACL and SAMBA, but doable. Handling disks in larger setups is complex and time consuming in Linux. The reason are disk names like sda or nvme0n1 with partition names like sda1 or nvme0n1p1. At first glance this seems super easy.
The lsblk command lists all disks and partitions with their properties. Disks are ongoing enumerated with device names like sda, sdb, sde and so on. For a small homeserver with only a few disks, you can be happy with that, not so with a storage server with 10, 20 or hundred disks. The problem is that these device names are not stable. If you remove or add a disk, the disks got new ongoing device names. In a software raid like ZFS where disknames are part of a pool definition, this is not acceptable as ZFS may not find its disks after a reboot. The solution on Linux are dev by-id names that are stable. You can use them instead device names. During a ZFS pool import, you can select, which naming you want to use. This means that within a pool or in general, you can have both names. In a larger storage system, this complicates disk property handling ex in the following zfs status overview with additional infos not shown by a default zfs status.
My solution
I use dev by-id names only for zfs status listings.For my disk propety database, the processing of used/unused/addable/removable/replacable disks or any other asks like smart checks, I use the short device names from lsblk
to process other details
to produce
On Solaris/ OmniOS this is easier as there is only one naming method with current hardware: unique wwn names
I still prefer OmniOS Unix as its ultra minimalistic approach and the stability of Illumos ZFS is a guarantee for a troublefree system, especially when it comes to SMB ACL where Linux and SAMBA is a pain.
Now mainstream is more and more OpenZFS on Linux or Windows (nearly ready). Some newest OpenZFS features are not yet available in Illumos. This and the upcoming OpenZFS on Windows led to my decision to additionally support OpenZFS (any OS, additionally Storage Spaces on Windows) with my napp-it web-gui.
Porting ZFS management was the easier part. ACL management was not so easy with Posix ACL and SAMBA, but doable. Handling disks in larger setups is complex and time consuming in Linux. The reason are disk names like sda or nvme0n1 with partition names like sda1 or nvme0n1p1. At first glance this seems super easy.
The lsblk command lists all disks and partitions with their properties. Disks are ongoing enumerated with device names like sda, sdb, sde and so on. For a small homeserver with only a few disks, you can be happy with that, not so with a storage server with 10, 20 or hundred disks. The problem is that these device names are not stable. If you remove or add a disk, the disks got new ongoing device names. In a software raid like ZFS where disknames are part of a pool definition, this is not acceptable as ZFS may not find its disks after a reboot. The solution on Linux are dev by-id names that are stable. You can use them instead device names. During a ZFS pool import, you can select, which naming you want to use. This means that within a pool or in general, you can have both names. In a larger storage system, this complicates disk property handling ex in the following zfs status overview with additional infos not shown by a default zfs status.
My solution
I use dev by-id names only for zfs status listings.For my disk propety database, the processing of used/unused/addable/removable/replacable disks or any other asks like smart checks, I use the short device names from lsblk
to process other details
to produce
On Solaris/ OmniOS this is easier as there is only one naming method with current hardware: unique wwn names
Last edited:
