zed

Open specific paths in Zed

$ zed [path/to/file_or_directory1 path/to/file_or_directory2 ...]

$ zed [path/to/project] --foreground

$ zed [path/to/project] [[-n|--new]]

$ zed [path/to/file]:[line_number]:[column_number]

$ zed --diff [path/to/old_file] [path/to/new_file]

zed [options]

-f
    Run in foreground; do not daemonize.

-n
    Dry run; do not execute any actions.

-v
    Enable verbose logging.

-V
    Print version information and exit.

-c path
    Specify an alternate configuration file path. Default is /etc/zfs/zed.d/zed.rc.

-l path
    Specify an alternate log file path. Default is /var/log/zed.log.

-p path
    Specify an alternate PID file path. Default is /var/run/zed.pid.

-d path
    Specify an alternate directory for event handling scripts. Default is /etc/zfs/zed.d.

-e secs
    Set the event timeout in seconds. Default is 300 seconds.

-h
    Display a help message and exit.

zed is the ZFS Event Daemon, an essential component for managing and monitoring ZFS file systems. It runs in the background, continuously listening for events generated by the ZFS kernel module. These events can include changes in pool status, disk errors, hot spares being activated, or scrub operations completing.

When an event occurs, zed evaluates it against a set of configured rules and can execute predefined scripts located in a specific directory (typically /etc/zfs/zed.d). This allows for automated responses to ZFS-related incidents, such as sending email alerts, replacing failed disks, or performing remedial actions.

zed greatly enhances the reliability and maintainability of ZFS storage systems by providing proactive detection and automated handling of critical events, reducing the need for manual intervention and improving overall data integrity. It's a crucial part of an OpenZFS deployment for robust monitoring.

• zed requires a properly configured ZFS environment to function effectively.
• The effectiveness of zed heavily depends on the quality and robustness of the event handling scripts located in its configured script directory.
• Care must be taken when configuring automated actions, as incorrect scripts could lead to unintended system behavior or data loss.
• It operates on the events generated by the ZFS kernel module; if the module is not loaded or ZFS is not in use, zed will not have events to process.

The primary configuration for zed involves placing executable scripts (typically shell scripts) within the /etc/zfs/zed.d directory. These scripts are triggered based on the ZFS event names. For instance, a script named ZFS_POOL_IO_FAIL.sh might be executed when an I/O error occurs on a ZFS pool.

zed passes several environment variables to the executed scripts, providing context about the event, such as ZEVENT_POOL, ZEVENT_VDEV, ZEVENT_EID, and ZEVENT_TYPE. Scripts use these variables to identify the specific nature of the event and take appropriate action.

On modern Linux distributions, zed is typically managed by systemd, with units like zed.service ensuring it starts automatically at boot and can be managed via systemctl start zed or systemctl status zed.

The zed daemon is an integral part of the OpenZFS project, which emerged from the original ZFS filesystem developed by Sun Microsystems. When Oracle acquired Sun and halted open-sourcing ZFS, the community initiated OpenZFS to continue its development and port it to various operating systems, including Linux. zed was developed as part of this effort to provide a robust, event-driven monitoring solution for ZFS pools, addressing the need for automated responses to array and storage health events that are common in enterprise storage. Its design reflects the self-healing and data integrity focus of ZFS, providing a mechanism for administrators to be proactively informed and to automate remediation actions, thereby strengthening the resilience and reliability of ZFS deployments across different platforms.

zfs(8), zpool(8), zdb(8), zvol(8), udev(7)