Speculative prefetch for reordered requests

[amotin]

Before this change speculative prefetcher was able to detect a stream only if all of its accesses are perfectly sequential. It was easy to implement and is perfectly fine for single-threaded applications. Unfortunately multi-threaded network servers, such as iSCSI, SMB or NFS usually have plenty of threads and may often reorder requests, preventing successful speculation and prefetch.

This change allows speculative prefetcher to detect streams even if requests are reordered by introducing a list of 9 non-contiguous ranges up to 16MB ahead of current stream position and filling the gaps as more requests arrive. It also allows stream to proceed even with holes up to a certain configurable threshold (25%).

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)
• 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]

It seems 4MB reorder distance (value of zfetch_min_distance) I've chosen originally is not sufficient for some workloads with large read-ahead. I've made it configurable separately and increased it to 16MB. I've also added one extra block for a case of misaligned requests.

[clhedrick]

If you think tuning may be application-specific, it should be a file system parameter, since systems often have applications of vary different types. If you think the same parameters can work for everyone, and just want to be able to experiment, then I guess module parameters are fine.

[amotin]

@clhedrick I think it should be pretty universal. There may be no perfect answers, but it should be good enough. Having it per dataset I see excessive.

[behlendorf]

Very nice. Keeping this a system-wide policy seems reasonable to me. Applications which know better can already use fadvise(2) anyway. Given the large number of service threads used by some some network servers we may find we want to tweak the default so thanks for making this easily tunable.