Improper eject breaks zpool

[Synchro]

If you eject a ZFS disk (single pool on USB) from the finder without a zpool export, disconnect the disk, then reconnect it (i.e. business as usual for an external drive), all zpool commands (even simple things like zpool list) hang and can't be killed. I suspect this is because the reconnected disk doesn't necessarily get the same disk number, so zpool is waiting for a non-existent device.

I know that the correct solution is to always export before device removal, however, zpool shouldn't break so fatally. If I had any other pools, I would be completely cut off from them from this simple error.

[ilovezfs]

This is the point of importing by-id or by-serial or by-path, and why InvariantDisks was implemented. So I'd say this is solely a documentation issue at this point.

[ilovezfs]

Duplicates:
#167
#258
Related:
#178

[Synchro]

I'm not disputing that that's the proper way to do it, but zpool breaking (apparently unrecoverably) for any reason surely isn't a documentation issue? Producing some kind of 'device not found' error would be more appropriate. Hanging and requiring a reboot to recover isn't very robust.

[ilovezfs]

With respect to improper eject issues not related to disk renumbering,
#285

[Synchro]

I've since found that this problem not only breaks zpool, but also breaks any attempt to mount any other file system too - for example plugging in an HFS+ flash drive does not work after ejecting a zfs disk without exporting it. I fail to see how rendering the entire system unusable is a documentation issue. #258 mentions a timeout, but I'm not seeing any timeout behaviour - I've had zpool hang for several days.

[ilovezfs]

@Synchro The documentation issue is how to prevent disk renumbering, which is a separate issue from the consequences of eject without export. If you have new observations beyond what was reported in #285 then please comment there.

The timeout values used by InvariantDisks and zpool-import-all.sh have nothing to do with improper ejects.

You should try setting failmode=continue as I mentioned in the other issue to see if it affects the behavior subsequent to improper eject.

[ilovezfs]

As I mentioned here #285 (comment), this should now be fixed by 8c55b29. Note that this commit is included in 1.3.1/1.3.1-r2.

[Synchro]

Great news, thanks.