ZED/zfs-list-cacher.sh: don't exit on ignored event type

[InsanePrawn]

Motivation and Context

13d6598 excluded history_events from logging by default.
This breaks the zfs-list caching mechanism as it listens for those events to trigger cache updates.

Closes #11164.

Description

This change simply stops ignoring history_event type events again.
I suppose @don-brady wasn't aware of these being used by the zfs-list-cacher -> mount generator?

Alternatively, one could suggest leaving the new default and adding the configuration change to zfs-mount-generator(8), making the instructions to get it up and running a little more obscure-seeming and harder to properly automate when you want to preserve existing excludes in the file, with the advantage of a possibly maybe sleeker UX for everyone else. While I understand the argument, especially now that this isn't just ZFS on Linux anymore, this would not be my preferred solution.

How Has This Been Tested?

Manually in my zed.rc, change works as expected after restarting ZED.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• (since 2.0?) Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[behlendorf]

I'd forgotten these were used by the zfs-list-cacher mechanism as well. The idea here as explained in the comment above was to only exclude them from syslog by default. What if instead of changing this default we removed the zed_exit_if_ignoring_this_event check from zfs-list-cacher.sh/in and replaced it with a check to only act on history events.

[InsanePrawn]

zed_exit_if_ignoring_this_event

Your suggestion sounds like the best of both worlds.
I hadn't even looked into that script since I assumed it wasn't even getting called.

I see no reason not to go that way but I'm also not familiar with ZED's architecture, as proven above.

[behlendorf]

Something like this should do the job, though I haven't tested it. The ZED calls each registered zedlet for each event, so it need only exit. If you could verify this does work and update the PR I think this would be a reasonable way to handle it.

-zed_exit_if_ignoring_this_event 
+[ "$ZEVENT_SUBCLASS" != "history" ] && exit 0

[InsanePrawn]

Something like this should do the job, though I haven't tested it. The ZED calls each registered zedlet for each event, so it need only exit. If you could verify this does work and update the PR I think this would be a reasonable way to handle it.

-zed_exit_if_ignoring_this_event 
+[ "$ZEVENT_SUBCLASS" != "history" ] && exit 0

Thanks. I was a little fast on pushing this, but wondered whether the switch case was enough of a check, since the old exit never protected us from non-history events anyway.
Will test and add your suggestion for maximum performance I guess.

[behlendorf]

since the old exit never protected us from non-history events anyway.

Yeah I noticed the same thing. It probably would be fine, but I figured we might as well make it explicit and do the check early.

[InsanePrawn]

@behlendorf Thanks for the guidance and merging!
Should there be a staging branch for 2.1 (there won't be a 2.0.1, right?) so we can start tracking backports like this as early as possible?
It might even be a good idea to create one immediately with every release?

[behlendorf]

In fact there will be 2.0.x releases:

#11314 (comment)

I went ahead and created a zfs-2.0.1-staging branch. Yes, I think it would be good to create one with each release.