Hacker News Reader

> were not in their expected locations on the new box

This is why one should not use sda/sdb or vda equivalent but use /dev/disk/by-uuid/

Can also use cachefile=none and the name does not matter at all. Every disk vdev has a unique guid in the ZFS label area. Without the pool cachefile the guid is used to reliably assemble the pool, instead of the kernel device path.

> I've loved seeing the progress of ZoL. Whether I use Ubuntu's prebuilt modules or Debian's DKMS-based setup, it Just Works. But I'm still leery of running Linux with a ZFS root filesystem. I've compromised and use ext4 for root and put my home directory on ZFS.

If you want to use ZFS for root, I can heartily recommend NixOS. I've never had a problem with it there. Of course there are other downsides, but there are plenty of upsides as well.

You were never at any risk in this scenario.

The only thing exporting a pool does is declare "I am not being mounted by someone else". The FAULTED state would be because the search paths for the devices didn't exist. Clearing /etc/zfs/zpool.cache and doing `zpool import -f` would fix it entirely (ZFS identifies the disks by UUIDs in the headers AFAIK).

Mostly true, but I've found this doesn't work if one of the drives is missing. It doesn't handle renames simultaneously with drive failure, or at least it didn't four years ago.

Using /dev/disk/by-uuid is always safe, though.