Bug #6477
opencache vdev in-use checks are insufficient at import
0%
Description
Even if the device is part of another pool (or non-zfs file system), zpool import will reclaim the cache vdev without comment and without requiring any sort of force. As a result, the pool or other file system on the cache device is silently destroyed.
This is especially dangerous on platforms where device numbers may change, and so any non-busy device is up for grabs if it happens to have the wrong name at the wrong time.
root@omni20150514:/root# zpool create -f assailant c2t5d0 cache c2t6d0
root@omni20150514:/root# zpool export assailant
root@omni20150514:/root# zpool create -f victim c2t6d0
root@omni20150514:/root# zpool export victim
root@omni20150514:/root# zpool import assailant
root@omni20150514:/root# zpool import victim
cannot import 'victim': no such pool available
root@omni20150514:/root# zpool create -f tiger c2t3d0 cache c2t4d0
root@omni20150514:/root# zpool offline tiger c2t4d0
root@omni20150514:/root# zpool export tiger
root@omni20150514:/root# zpool create -f lamb c2t4d0
root@omni20150514:/root# zpool export lamb
root@omni20150514:/root# zpool import tiger
root@omni20150514:/root# zpool import lamb
cannot import 'lamb': no such pool available
I noticed this while looking into Chris Siebenmann's post here:
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSImportBetterErrors
http://list.zfsonlinux.org/pipermail/zfs-discuss/2015-November/023832.html
https://superuser.com/questions/993695/zpool-import-with-missing-cache-device
via @planetsysad on Twitter
Updated by Richard Elling over 6 years ago
synopsis should be renamed to say "aux devices" rather than just "cache"
spares exhibit the same behaviour