4 ms·
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` r
by happymellon 4y ago
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.
- wokkel 4y agoUh, 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?
- vetinari 4y agoAt 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.
- happymellon 4y agoThis 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.
- tecleandor 4y agoI 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"
- michaelmrose 4y agoI 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.