[btrfs] add btrfs-specific bdi/read_ahead_kb

[motiejus]

Add a knob for the btrfs-specific bdi/read_ahead_kb. AFAIK this value is the upper limit of the btrfs read-ahead of the underlying file.

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test

/kind feature

/kind flake

What this PR does / why we need it:

Confusingly, this option is not related to /sys/block/sdX/queue/read_ahead_kb, which is what controls the read-ahead of the block device (regardless of what's in there). The current read_ahead_kb "special" mount option configures the value of the block device.

The default bdi/read_ahead_kb is 4MiB (on all the systems I've checked). Ext4 does not have this option and relies on the block-device specific readahead, which is 128KiB (again, on all the systems I've checked). After migrating to btrfs we have experienced a notable read amplification and tracked to this setting. Once we changed bdi/read_ahead_kb to 128, our IO utilization (and the properties of the underlying workload) became very similar to the one of ext4.

Which issue(s) this PR fixes:

Fixes #2155

Special notes for your reviewer:

Now that we have 3 btrfs-specific "special" mount options, I refactored the code and tests to make it less repetitive.

Does this PR introduce a user-facing change?:

add `btrfs-bdi-read_ahead_kb` to control btrfs-specific readahead.

[k8s-ci-robot]

Hi @motiejus. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[mattcary]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mattcary, motiejus

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [mattcary]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

@motiejus: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-gcp-compute-persistent-disk-csi-driver-e2e-arm	f6c8051	link	false	/test pull-gcp-compute-persistent-disk-csi-driver-e2e-arm
pull-gcp-compute-persistent-disk-csi-driver-e2e-windows-2022	f6c8051	link	false	/test pull-gcp-compute-persistent-disk-csi-driver-e2e-windows-2022

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.