evansus
commented
10 years ago @lundman Re:https://github.com/openzfsonosx/zfs/issues/201#issuecomment-47298835 yep about a week ago I updated find_by_path to validate vdev GUIDs unless creating or splitting the pool. If the validation fails there, then find_by_guid can kick in. I also had to update the logic for cache and spare devices, since they are labeled differently.
See https://github.com/openzfsonosx/zfs/commit/ed1463a6dc4b860714206880e8e1af71af69ba2b, https://github.com/openzfsonosx/zfs/commit/485713629f836d4ca1ebbf4d0ed8c3b267083ddb, https://github.com/openzfsonosx/zfs/commit/0c6e5cc431e7e314037e3862e06916b790467d70, https://github.com/openzfsonosx/zfs/commit/69dcad839c530b6284ef26553163ce382f9823d0 and https://github.com/openzfsonosx/zfs/commit/170ee299373964dcbbbbf1d22d08e5bc2aa97389. The last one, 170ee299373964dcbbbbf1d22d08e5bc2aa97389, fixed content missing from an old merge from upstream - you might want to consider cherrypicking that into master. At least when caches and spares are out of order, the validation in vdev_label.c / vdev.c should prevent it from being used.
That resolved the remaining degraded or faulted imports due to renumbered disks, since the devices are checked when there's still a chance to search for them. I've tested with renumbered data, log, cache, and spare vdevs and haven't had issues recently.
@rottegift has reported some panics that I haven't been able to replicate or completely decipher. But his pools, with several vdevs of each type per pool, are great test cases.
Perhaps you've already seen it, but I've been testing by running this script hotspares.sh -k in a VM. The 'outer' pool is on a vmware sata disk.
I also should clone that script and test it with only the 'inner' pool, backed by disk images or better yet VMware sata disks.
The only two issues I have run into had to due with zpool scrub on a root pool, on the iokit-boot branch. Also, adding a log device caused the boot-time import to fail, haven't debugged it much beyond removing the log device from that pool temporarily- I believe I just need to update vdev_iokit_find_pool slightly.
rottegift
JMoVS
Thanks for trying out the iokit replacement. It does indeed appear to function well, and receives almost identical benchmark score as master.
https://github.com/openzfsonosx/zfs/blob/vdev-iokit/module/zfs/vdev_iokit.c#L88
Better watchout with those comments, you just took out the clearing on line 93. But since it is the free function, it doesn't matter ;)
https://github.com/openzfsonosx/zfs/blob/vdev-iokit/module/zfs/vdev_iokit.c#L340 https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/fs/zfs/vdev_disk.c#L416
Is the plan to extend it to attempt to open_by_guid as well? I see you implemented something in vdev_iokit_util.cpp, is it part of your roadmap to add that ability? If it can handle the device /dev/diskX moving, then it would make it quite attractive.
:)