Open haraldrudell opened 2 years ago
In general, this is one of many reasons it's recommended you use /dev/disk/by-id/
or similarly stable paths, yes. (partuuid is great, but only helps once there's a labeled partition in the first place...)
With the not yet in a stable release vdev properties
, you should be able to tell ZFS "hey, disk 2 is now available at /dev/sde1 not /dev/sda1" without an export+import, as well, but that's not in a release yet.
It can be tricky to handle things like this purely automatically - if something pops up with the same on-disk data as the original disk, but visibly isn't the original disk, do you want it to be treated like it is? What if it's the original disk but over SATA/USB when it originally was not? What if it's an old offline backup copy? What if we're in a VM, and this is a copy of the disk I got by running cp while it was running? Sometimes you might want to have a second volume temporarily present and appearing to be the same, and hopefully ZFS doesn't conflate the two when they're visibly not.
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.
System information
Describe the problem you're observing
When a usb uas device disconnects it may change name from sdb to sdc. This causes zfs to suspend the pool and the pool cannot be cleared because the disk name is different. The system needs to be rebooted. Such disconnects will happen with usb no natter how great cables you have
If zfs vdev names are SCSI disk, a reboot is required for zfs to realize the data is present. This is cumbersome
zpool list -PLv lists /dev paths like /dev/sda
zpool list -v lists partition uuids like fe7ba39a-83c0-4059-af23-82ac3f3bcef0, representing /dev/disk/by-partuuid/fe7ba39a-83c0-4059-af23-82ac3f3bcef0
if zpool list -v displays sda, the pool is at risk
For my newer vdevs, I use partition uuid so that this is not a problem, because wherever the partition is, it has the same uuid and zfs will find it. If you have 1+1, you can reattach live to change vdev names to partition uuid using zpool attach
zfs disk vdev does use gpt partitions but still cannot find them if sda name has changed. A reboot is required because zfs SUSPENDS the pool and zfs commands do not work after that
Desirable
zfs to find its vdevs even if SCSI disk name changes. If zfs were to use partition uuid, the data could be moved to a different disk and reattached on a running system