ZFS should handle unknown/invalid vdev devids gracefully
With #14686 we'll introduce new devid types for NVMe devices. This works nice and well even for root pools on NVMe: ZFS will notice that the vdev devids have changed, but since the pool and vdev GUIDs still match it'll still succeed to open the pool. The vdev labels will be updated with the new devids.
But there's a problem when going back to an older BE before the integration of #14686. A kernel before #14686 will not know the new devid types, and consequently ddi_devid_str_decode() will fail on them.
ZFS calls ddi_devid_str_decode() as part of vdev_disk_open(), and a failure to decode the devid will be understood as a corrupted vdev label. Consequently, ZFS will fail to open the vdev and the pool, panicking at boot if this was the root pool.
There is no good solution to this. A rather blunt method to allow going back to an older BE before #14686 is to bypass all devids using the method introduced with #9683: Setting zfs:vdev_disk_bypass_devid=1 in the older BE's /etc/system, or even during boot using kmdb. This will cause ZFS to ignore all devids, updating the pool labels with the old devids known and understood by the older kernel.
To make life a little easier, we can change ZFS to ignore unknown/invalid devids just as if vdev_disk_bypass_devid was set. Holding off integration of #14686 for some time will give us a time window in which we can safely go back to an older BE after #14686 integrates.
Updated by Electric Monk over 1 year ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 29621f011bb9ea4f2d9ea887e971bbb3910ee931 Author: Hans Rosenfeld <firstname.lastname@example.org> Date: 2022-06-24T15:23:06.000Z 14745 ZFS should handle unknown/invalid vdev devids gracefully Reviewed by: Gordon Ross <Gordon.W.Ross@gmail.com> Reviewed by: Toomas Soome <email@example.com> Approved by: Dan McDonald <firstname.lastname@example.org>