kdave
scrub start: set bwlimit using cgroups or systemd-start
Bandwidth limit per device can be set by systemd-run -p IOBandwidthReadMax=/dev/sdx 10M' btrfs scrub start -B / . The cgroup2 is set up on systems by default.
- document that this can be used for bandwidth limiting
- provide an option to run that transparently
- document sysfs bwlimit (kernel 5.14) as a fallback
Now documented, there's a new command btrfs scrub limit to show the limits, setting will be possible in the future too.
IIUC, the scrub IO is carried out from the actual btrfs-prog process? (I.e. no deferral to kthreads.)
When a scrub thread waits for IO, can it possibly (exclusively) hold any (btr)fs locks?
No, the user space part of scrub starts an ioctl and all the io is done by kernel, running from the user process context, ie. no kthread. The locks are managed by kernel and user space cannot interfere with that.
user space cannot interfere with that.
No argument about that. But the holder could be waiting (longer) for a throttled IO. Or are locks released before issuing the IO?
Edit: I only want to warn about possible "propagation" of the throttling via a shared lock to other FS users. If there is no such lock, this throttling likely nails the issue of too greedy scrub.
I haven't found any logic that would block threads outside of scrub. It's running from its own context and the throttling happens on the IO submission, no big locks are held there for a long time (other than to set up data for io, like any other regular io). The special case of device replace can hold some locks longer but still during the setup phase.