4 ms·

I first heard of ZFS back around 2009, and I don't regret my decision to go with it. But it isn't a panacea either. I nearly wiped out my storage pool one time

I first heard of ZFS back around 2009, and I don't regret my decision to go with it. But it isn't a panacea either. I nearly wiped out my storage pool one time when I moved it to a different machine without exporting it first. The pool came off an OpenIndiana system and the drives were not in their expected locations on the new box. Whoooops, the whole pool showed up FAULTED. After my panic settled down, I decided to put them back where they were, and the pool came up fine. whew 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.

Filligree 5y ago
> 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.
XorNot 5y ago
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).
- Filligree 5y ago
  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.
vero2 5y ago
> 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/
- matja 5y ago
  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.

Filligree 5y ago

> 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.

XorNot 5y ago

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).

Filligree 5y ago
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.

vero2 5y ago

> 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/

matja 5y ago
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.