Add knob to disable slow io notifications

[oshogbo]

Motivation and Context

Adding a knob allows disabling the slow_io check on a single vdev. Some users have reported that it breaks their enterprise configuration when one or more vdevs are using fiber channels with redundancy. Another reason to disable the check might be when a vdev is damaged, but we still want to force some resilvering from it.

Description

Add a knob to disable slow I/O event generation for a single vdev.

How Has This Been Tested?

New test has been added.

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)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• 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.

[amotin]

I wonder if this feature partially duplicates slow_io_n/slow_io_t? Though I may not understand their meaning.

[allanjude]

Would it make sense to move the panic() into vdev_prop_get_objid() to save having to test it everywhere it is used?

[oshogbo]

We use it in vdev_prop_get_int, and then it is used for example here to generate an error.

So I would leave it as is for a consumer to decide if it should panic or not.

[oshogbo]

I wonder if this feature partially duplicates slow_io_n/slow_io_t? Though I may not understand their meaning.

I see this new feature as a supplement to slow_io_n/slow_io_t. Those settings serve two purposes: they let zpool status report how many slow I/Os have occurred, and they generate events for ZED/zfsd so it can decide whether to downgrade the pool. However, sometimes you don’t want the pool downgraded, but you still might want some accounting on slow I/O.

For example, in multipath environments (as has been pointed out multiple times on X/Twitter), pools have unexpectedly been downgraded. From my point of view, this feature is useful when you know a device is failing but still want to extract as much throughput as possible during recovery.

Simply raising slow_io_n/slow_io_t to very high values isn’t a great solution, and seems like an bypass not solution — how high is “high enough”? A single knob to control this behavior makes more sense in these scenarios.