Hi,
I’m a developer of the BFQ I/O scheduler [1, 2], and this topic is about
the techniques used to guarantee I/O bandwidth to clients, containers,
virtual machines and any other type of entities accessing shared
storage. I’ve been suggested to create this topic by a Google storage
manager, who thinks that my results might be interesting for some of
you guys, or maybe even useful for some company.
I found out that the above techniques entail dramatic throughput
losses: up to 80-90% of the throughput reachable by your storage.
Experts, including people working on these techniques, confirmed this
severe underutilization. So I decided to analyze the problem, and put
my results in a short article: http://ow.ly/vsrW50mBAGl
On the bright side, I also tried to extend BFQ so as to become a
viable solution to this problem. BFQ now seems to reduce the loss to
just 10%. This result is reported in the article too.
If someone has any question, I’ll be happy to answer, if I can
I guess you can now find bfq in every distribution. A different story is whether the distribution is configured to use it as the default I/O scheduler fr every device. More and more distributions are being configured this way. SUSE and Fedora are two examples of top distributions that are currently switching to, or considering to switch to bfq as default I/O scheduler. Chromium OS has already done it, but I guess this last example is little relevant in this discussion
As for flatcar and container Linux, I’m afraid they’ll have to give up CFQ soon, as CFQ belongs to the (now) old legacy Linux I/O stack, which is gone from Linux 5.0. This is actually one of the reasons why several distributions are considering BFQ, as it is the most natural replacement for CFQ.
Should I have news soon, I’ll try to remember to share them in this discussion.
