4 ms·

Oh, don't worry, ZFS has a set of its own gotchas. My favorite is #8885.

• chungy 5y ago
  That issue sounds like a configuration error; I don't even encounter said "gotcha" on Linux systems. Even if you grant it to be a simple bug, it's not exactly a grave design issue with ZFS.
  • vetinari 5y ago
    It just kind of sucks, when it happens, you are thrown into recovery console at boot and there is no solution. From what I saw, it happened if the disk initialization took longer and ZoL looked for its pools before all disks were found. It hints at improper dependencies in ZoL startup.
• paulmd 5y ago
  for reference: this is referring to a systemd service script (systemd-udev-trigger/systemd-udev-settle) with a race condition where the pool may not be mounted by the time systemd tries to use it. https://github.com/openzfs/zfs/issues/8885 https://github.com/openzfs/zfs/issues/8885 that's (a) not really a bug in ZFS, and (b) "fails to boot sometimes" is pretty different from btrfs shitting the bed and corrupting its pool. There was one of those recently with ZFS iirc (and specifically only ZFS-on-Linux) but they are fairly rare and notable when they occur! (As a general statement, ZoL is less mature than ZFS-on-FreeBSD and likely (perhaps) to continue to be so given the licensing issues. I've also run into some problems where I can't send a dataset from FreeBSD to a ZoL pool (but rsync works fine). But again, generally bugs that actually lead to data loss are exceedingly rare.)
  • CorrectHorseBat 5y ago
    >As a general statement, ZoL is less mature than ZFS-on-FreeBSD That's strange since FreeBSD actually moved to ZoL a while ago