You added a dedicated log device, or SLOG, to your pool to speed up sync writes, thinking you were being clever. Most folks assume ZFS handles a failed SLOG device gracefully, but in my experience, the default behavior can be a shock. If that SSD pulls a disappearing act, your entire pool can become inaccessible until you either replace it or force the pool to import without the log, potentially losing data in the process.

Why the log device is a single point of failure

When a synchronous write hits your system, ZFS writes the transaction to the SLOG before telling the application it is safe. If the SLOG device vanishes, the pool state is technically inconsistent for those uncommitted transactions. While ZFS prevents you from mounting a pool that is missing a log, you are stuck in a recovery loop. You do not want to be digging through man pages at three in the morning just to realize your storage is locked tight.

zpool import -m -o readonly=on <poolname>

• The -m flag tells ZFS to ignore missing log devices when importing the pool.
• Use read-only mode first to verify your data is actually there before trying to write.
• Once imported, remove the dead log device immediately to return to normal operations.
• Mirror your SLOG devices if you care about uptime, because a single cheap SSD is just a disaster waiting to happen.

If you are running production workloads on a single slog device without a mirror, you are essentially gambling with your data’s persistence during a power loss or hardware failure. It is much cheaper to throw a second cheap SSD into a mirror than to explain to your boss why the entire database volume is suddenly offline. Keep a spare device in the rack or just use a mirrored pair from the start.