I've had more issues with my ZFS arrays than the BTRFS ones.

The Linux implementation is pretty awful, with it demanding that it uses the absolute `/dev/sdx` reference even if you try to build it using serials or other unchaging reference.

Replace a disk and then after the next restart it fails to bring up the RAID because `sdf` points to a different disk. At least BTRFS uses internal UUIDs so can bring up the arrays when the disk ids change.

Fairly fundamental stuff, rather than complaining about an option not being enabled by default.

Uh, using /dev/disk/by-id to assemble a zfs array is pretty standard for zol. I never use device names and shuffling disks has never required any manual intervention on my part. Was this a very old ZoL?

At a time, it was the default, and you had to go out of your way to use /dev/disk/by-id (you had to create your pool, export it, and then import it by id), only to be hit by another issue, where when preparing grub, it was looking for the IDs straight in /dev (that's how I learned that ZPOOL_VDEV_NAME_PATH=YES exists).

Yeah, putting / on zfs was not smart. Nowadays, when the distro doesn't support it out of the box and doesn't come with kernel+bootloader+zfs tested together (i.e. proxmox, ubuntu), I wouldn't do it.

This was last year on Ubuntu.

I assembled the zfs array using by-id, but after a reboot zfs reports the drives as being on /dev/sdx.

I don't know if you're talking about a veeeeery old implementation or haven't properly configured it, but you can use both the device reference or the partition UUID.

This is one of my systems using both identifications:

  root@multivac[~]# zpool status
    pool: boot-pool
   state: ONLINE
    scan: scrub repaired 0B in 00:01:33 with 0 errors on Fri Dec  9 03:46:34 2022
  config:

        NAME        STATE     READ WRITE CKSUM
        boot-pool   ONLINE       0     0     0
          sdg3      ONLINE       0     0     0

  errors: No known data errors

    pool: multivac-slow
   state: ONLINE
    scan: scrub repaired 0B in 07:05:51 with 0 errors on Sun Nov 20 09:05:55 2022
  config:

        NAME                                      STATE     READ WRITE CKSUM
        multivac-slow                             ONLINE       0     0     0
          mirror-0                                ONLINE       0     0     0
            ad3395b6-ac43-453c-9ba2-cf65542cb710  ONLINE       0     0     0
            2c423fe3-07a4-44cb-bc39-8b267c79d8c3  ONLINE       0     0     0
          mirror-1                                ONLINE       0     0     0
            8ca9d5a2-04cb-47a0-987a-8b3d27326975  ONLINE       0     0     0
            bec4c67f-fa41-4ab2-907f-0e5b1e052300  ONLINE       0     0     0
        cache
          bfef4d7f-c484-4c37-a0b7-81d59fa1e189    ONLINE       0     0     0
  root@multivac[~]# blkid|grep zfs_member
  /dev/sda2: LABEL="multivac-slow" UUID="4053361656876756561" UUID_SUB="363024978934966364" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="2c423fe3-07a4-44cb-bc39-8b267c79d8c3"
  /dev/sdd2: LABEL="multivac-slow" UUID="4053361656876756561" UUID_SUB="10877444988141002268" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="8ca9d5a2-04cb-47a0-987a-8b3d27326975"
  /dev/sdb2: LABEL="multivac-slow" UUID="4053361656876756561" UUID_SUB="9244362969528724588" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="ad3395b6-ac43-453c-9ba2-cf65542cb710"
  /dev/sdc2: LABEL="multivac-slow" UUID="4053361656876756561" UUID_SUB="11658072268678819533" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="bec4c67f-fa41-4ab2-907f-0e5b1e052300"
  /dev/sdg3: LABEL="boot-pool" UUID="13291833732043257716" UUID_SUB="15424416082895860251" BLOCK_SIZE="4096" TYPE="zfs_member" PARTUUID="b6c0b302-7599-4862-888b-be6f7a85b970"

I think the advice was to simply use /dev/disk/by-id/foo when originally creating a pool and one would never have a problem with /dev/sda being a different disk and this was true at least back to 2015ish.