ZFSD(8)

💅 ZFSD(8) — the ZFS fault management daemon, bestie edition ✨

okay so real talk: this page is from the System Manager's Manual section 8, and it's about zfsd — the little daemon that fixes ZFS boo-boos the kernel literally cannot fix by itself. buckle up 🎀

---

✨ SYNOPSIS ✨

zfsd [-d]

🦋 DESCRIPTION 🦋

So here's the vibe: zfsd attempts to resolve ZFS faults that the kernel can't resolve by itself, no cap. It listens to devctl(4) events — that's literally how the kernel tells userland "hey girl, something happened" like I/O errors and disk removals 💀 — and then it tries to fix the drama by activating or deactivating hot spares and onlining offline vdevs. main character energy fr fr.

The following options are available:

• -d — run in the foreground instead of daemonizing. babygirl just wants to be seen 👀

---

🌸 how do i even talk to it

Here's the tea: system administrators never interact with zfsd directly. Never ever. Instead you control its behavior indirectly through zpool configuration. There are exactly two ways to influence zfsd: assigning hot spares, and setting pool properties. Currently, only the autoreplace property has any effect. See zpool(8) for the deets 🫶

---

👑 the faults it will absolutely handle for you

zfsd will attempt to resolve the following types of fault:

🍓 device removal

When a leaf vdev disappears, zfsd will activate any available hot spare. gone girl behavior, it just gets a replacement 💅

🧚 device arrival

When a new GEOM device appears, zfsd will attempt to read its ZFS label, if any. If it matches a previously removed vdev on an active pool, zfsd will online it. Once resilvering completes, any active hot spare will detach automatically. slay, self-cleaning ✨

If the new device has no ZFS label but its physical path matches the physical path of a previously removed vdev on an active pool, and that pool has the autoreplace property set, then zfsd will replace the missing vdev with the newly arrived device. Once resilvering completes, any active hot spare will detach automatically. same energy, different path, iykyk 🌈

💀 vdev degrade or fault events

If a vdev becomes degraded or faulted, zfsd will activate any available hot spare.

🔥 I/O errors

By default, if a leaf vdev generates more than 50 I/O errors in a 60 second period, then zfsd will mark that vdev as FAULTED. ZFS will no longer issue any I/Os to it. zfsd will activate a hot spare if one is available. The defaults can be changed by setting the io_n and/or io_t vdev properties. See vdevprops(7) for details.

⭐ I/O delays

By default, if a leaf vdev generates more than delayed 8 I/O events in a 60 second period, then zfsd will mark that vdev as FAULTED. ZFS will no longer issue any I/Os to it. zfsd will activate a hot spare if one is available. The defaults can be changed by setting the slow_io_n and/or slow_io_t vdev properties. See vdevprops(7) for details.

🎀 Checksum errors

By default, if a leaf vdev generates more than 50 checksum errors in a 60 second period, then zfsd will mark that vdev as DEGRADED. ZFS will still use it, but zfsd will also activate a hot spare if one is available. The defaults can be changed by setting the checksum_n and/or checksum_t vdev properties. See vdevprops(7) for details.

💖 Spare addition

If the system administrator adds a hot spare to a pool that is already degraded, zfsd will activate the spare. she said "i gotchu" 🫶

🌸 Resilver complete

zfsd will detach any hot spare once a permanent replacement finishes resilvering.

🦋 Physical path change

If the physical path of an existing disk changes, zfsd will attempt to replace any missing disk with the same physical path, if its pool's autoreplace property is set.

---

zfsd will log interesting events and its actions to syslog with facility daemon and identity [zfsd]. it's giving "dear diary" but make it syslog 📓✨

🎀 FILES 🎀

• /var/db/zfsd/cases — when zfsd exits, it serializes any unresolved casefiles here, then reads them back in when next it starts up. not her forgetting her own lore 🙈

🔍 SEE ALSO 🔍

devctl(4), vdevprops(7), zpool(8)

🌈 HISTORY 🌈

zfsd first appeared in FreeBSD 11.0. vintage!! 👑

🫶 AUTHORS 🫶

zfsd was originally written by Justin Gibbs <gibbs@FreeBSD.org> and Alan Somers <asomers@FreeBSD.org>. legends, literally 💜

💀 TODO 💀

In the future, zfsd should be able to resume a pool that became suspended due to device removals, if enough missing devices have returned. bestie's working on it, manifesting 🧚✨

---

ok that's the whole page, no skips, no cuts 💯 this edition came to you from Debian, dated February 20, 2024 — take care of yourselves and your pools, mwah 🎀💖