ZFS Unexpected Disknames in RaidZ-1

[Martin Jangowski]

My name is Martin and I'm using FreeBSD for nearly 30 years now (my first server connected to the internet was FBSD 2.x in 1995). However, FBSD sysadmin is not my primary occupation, so there are things that baffle me...

I got in possession of a FBSD-Server running 13.2 (long story). It is a HP Microserver Gen 8 with three 3TB disks, running with ZFS RaidZ-1. When I looked at "zpool status" I found this:

pool: zroot
state: ONLINE
scan: scrub repaired 0B in 1 days 04:04:26 with 0 errors on Tue Apr 22 12:03:42 2025
config:

    NAME                               STATE     READ WRITE CKSUM
    zroot                              ONLINE       0     0     0
      raidz1-0                         ONLINE       0     0     0
       ada0p3                         ONLINE       0     0     0
       diskid/DISK-WD-WCC4N1KD0YCRp3  ONLINE       0     0     0
       diskid/DISK-WD-WCC4N4VLZVAEp3  ONLINE       0     0     0

errors: No known data errors

A "ls -l /dev/ada*" shows

root@xxx:~# ls -l /dev/ada*
crw-r-----  1 root operator 0x61 Jul 28 07:10 /dev/ada0
crw-r-----  1 root operator 0x62 Aug  2 04:05 /dev/ada0p1
crw-r-----  1 root operator 0x63 Jul 28 07:10 /dev/ada0p2
crw-r-----  1 root operator 0x64 Jul 28 07:10 /dev/ada0p3
crw-r-----  1 root operator 0x67 Jul 28 07:10 /dev/ada1
crw-r-----  1 root operator 0x66 Jul 28 07:10 /dev/ada2

The partitions of the two ada1 and ada2 disks show up under /dev/diskid.

How did that happen? Can I revert this to the usual ada<n>p<x> scheme (and is this desirable)? I fear boot problems should ada0 ever get problems...

Martin

 

[SirDice]

I fear boot problems should ada0 ever get problems...

ZFS uses internal structures to identify the disks, it's not going to care where the disk is actually attached physically. You can take them out, reshuffle them, put half of them on a different controller and things will still continue to work as if nothing happened.

The only thing that might potentially freak out is the FreeBSD bootloader.

 

[Maturin]

Nothing is wrong with your pool. It's just a tiny inconsistency of no importance and long names, which may be weird looking, but actually useful, since those are the serial numbers of the drives, which are also printed on the outside of the drive's enclosure, so very good to identify the correct drive.
It's just that ada0 contains three partitions, and p3 is part of the pool by it's physical hardware name, no label, so bond to its SATA port, while the other two ones are added completely to the pool, so ZFS attached them by their disk ID.

Can I revert this to the usual ada<n>p<x> scheme (and is this desirable)?

Not really desirable, no.
You could, but I wouldn't recommend it. It causes you trouble only.
As SirDice said, the both long named disks are bond into the pool by their ID, which means their places at the SATA port is of no importance.
While names like ada0, ada1, ada2... come from the order the system detects the drives. If for example ada0 contains the only EFI/system partition (as it seems to be), replacing or adding drives or above all change their places at the SATA ports can highly probable result in the drive formerly known as ada0 then gets another number, and another drive becomes ada0, so no system is detected anymore, so your system does not boot anymore.
Personally I wouldn't touch that pool unless I really had to.

 

[T-Daemon]

Can I revert this to the usual ada<n>p<x> scheme

Try setting the following variables in /boot/loader.conf (automatically added default settings when installing Root-on-ZFS by menu guided installer):

kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"

Reboot system.

Explanation:

% sysctl -d kern.geom.label.disk_ident.enable
kern.geom.label.disk_ident.enable: Create device nodes for drives which export a disk identification string

% sysctl -d kern.geom.label.gptid.enable
kern.geom.label.gptid.enable: Create device nodes for GPT UUIDs