> On May 17, 2017, at 5:12 PM, Eric A. Borisch <ebori...@gmail.com> wrote: > > Short version: > > It's not the -f causing the problem, it's the parsing and (double) > importing via /boot/zfs/zpool.cache that is.
I was unclear… _how_ do you get the double entry in zpool.cache _except_ by using the -f option with a zpool that is already imported ? > Longer story: <snip> > So it is not the import with -f that is causing the problem here, it is the > following reboot when the zpool.cache file is parsed and ensuing > double-import. I would maintain that it is the combination of the import of an already imported zpool which causes the double entry in the zpool.cache in combination with a recent rename of the zpool. Would (did) the import without the force fail ? The last host this zpool was imported on was _this_ host, so the “is this zpool used by another host” check would not stop such an import. Or, is the zpool rename not updating the name in the zpool.cache file ? I don’t currently have a test system available or I would experiment... > (As an aside, using the -f is required to import a pool last > used and not exported by another system, and is a common and documented use > case. If you look at the code, it turns on a the ZFS_IMPORT_ANY_HOST flag, > not an 'ignore all errors' state. There is a separate -F which is more > 'force'-ish (turns on rewinding).) There are times when it is necessary to force an operation. One of the underlying assumptions is that the person using the force option _knows_ with a very high degree of certainty that the zpool is not in use, either by another system or the same system. _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
