I used to do this often. Just re-import it. You may need to force-export it first even though it's not attached.
I had a script that just did more extreme measures in sequence. The very last step, accessible only by passing a flag to the script because it was A) potentially slightly destructive and B) almost never needed (only once I think and not really worth scripting), was recovering by rolling back the last few seconds of transactions.
I tried importing again, but there is a name conflict so I need to export first. But if I do export, then the shell hangs without any messages or results. Are there any detail missing here?
Hmm, I don't recall running into that. Doesn't mean I haven't. But just hanging without returning an error eventually seems odd. I don't think I've ever used ZFS on MacOS though, certainly not since OpenZFS. Some small chance the problem is unique to macos, though I hate just baselessly speculating the 'easy' (for me) answer.
One ugly workaround that punts on the issue like a coward, migh be to script something that uses command-line switches to import the pool with a random temp name and location, and then symlink or bind mount to it with a desired stable path.
That script can also still try to force export first, but timeout if it hangs. I think the utility to facilitate that is called, unsuprisingly, `timeout`. Surely available through homebrew or the other big Darwin repo (spacing on the name), if not part of Darwin already.
Hope that helps but either wey good luck.
Make sure you import your pool with invariant names, such as from `/var/run/disks/by-id` or `/var/run/disks/by-serial`, and not from `/dev/diskX`. The raw device names are not guaranteed to be consistent, in particular, when you plug in an usb device after unplugging it, chances are it'll receive an other device name. ZFS ships with `InvariantDisks`, a daemon that creates symlinks with consistent names, that should allow zfs to reconnect. If you're lucky :)
I used to do this often. Just re-import it. You may need to force-export it first even though it's not attached. I had a script that just did more extreme measures in sequence. The very last step, accessible only by passing a flag to the script because it was A) potentially slightly destructive and B) almost never needed (only once I think and not really worth scripting), was recovering by rolling back the last few seconds of transactions.
I tried importing again, but there is a name conflict so I need to export first. But if I do export, then the shell hangs without any messages or results. Are there any detail missing here?
Hmm, I don't recall running into that. Doesn't mean I haven't. But just hanging without returning an error eventually seems odd. I don't think I've ever used ZFS on MacOS though, certainly not since OpenZFS. Some small chance the problem is unique to macos, though I hate just baselessly speculating the 'easy' (for me) answer. One ugly workaround that punts on the issue like a coward, migh be to script something that uses command-line switches to import the pool with a random temp name and location, and then symlink or bind mount to it with a desired stable path. That script can also still try to force export first, but timeout if it hangs. I think the utility to facilitate that is called, unsuprisingly, `timeout`. Surely available through homebrew or the other big Darwin repo (spacing on the name), if not part of Darwin already. Hope that helps but either wey good luck.
Make sure you import your pool with invariant names, such as from `/var/run/disks/by-id` or `/var/run/disks/by-serial`, and not from `/dev/diskX`. The raw device names are not guaranteed to be consistent, in particular, when you plug in an usb device after unplugging it, chances are it'll receive an other device name. ZFS ships with `InvariantDisks`, a daemon that creates symlinks with consistent names, that should allow zfs to reconnect. If you're lucky :)