LEIL-GLOBALIOLIMITS.CFG(5)

πŸ“¦ version 5.12.0, in nixpkgs unstable

πŸŽ€ leil-globaliolimits.cfg β€” like, the whole manual, bestie πŸŽ€

Okay so you picked up the leil-globaliolimits.cfg page from section 5 of the manual β€” that's the file-formats corner of the man-page universe, iykyk. Sit down, grab a strawberry πŸ“, and let's get into it.


✨ NAME ✨

leil-globaliolimits.cfg β€” the global I/O limiting configuration file. That's it, that's the whole name. Short, iconic, does exactly what it says on the tin. πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

So the file leil-globaliolimits.cfg literally contains the configuration of the global I/O limiter. That's the whole vibe. It's the settings file for the thing that decides how much bandwidth everybody gets. No cap.


🌸 SYNTAX 🌸

The syntax is, and I cannot stress this enough, exactly this:

option value

That's it. Option, then a value. Simple.

And listen β€” lines starting with the # character are ignored. Commented out, swept under the rug, not invited to the party. πŸ™ˆ


πŸ‘‘ OPTIONS πŸ‘‘

Here are the configuration options, one by one, no skips:

  • subsystem <subsystem> β€” this is the cgroups subsystem that clients get classified by. If you leave it unspecified, then literally all clients are considered unclassified (peep the next bullet for what that means).
  • limit unclassified <throughput in KiB/s> β€” this is the special little entry for clients that don't match any group you specified in the config file. OR, plot twist, it applies to all clients if subsystem is unspecified. Two rules, one option, main character energy.
    • If this entry is unspecified and subsystem is unspecified too β†’ I/O limiting is disabled entirely. Nothing gets limited. Free-for-all.
    • If this entry is unspecified but subsystem is specified β†’ unclassified clients are not allowed to perform I/O at all. Like, zero. Blocked. 😭
  • limit <group> <throughput in KiB/s> β€” sets the limit for clients that belong to the cgroups group <group>. And here's the important bit in LeilFS: subgroups of <group> constitute independent groups. They are not allowed to use <group>'s bandwidth reservation, and they don't count against <group>'s usage. So like, they're related but they're not sharing the aux cord. 🎧

πŸ’– EXAMPLES πŸ’–

Right, the fun part. Here's what this actually looks like in the wild:

# empty file

So this is an empty file. I/O limiting is disabled, no limits are enforced. Nothing is happening. It's giving ✨peace and quiet✨.

limit unclassified 1024

All clients are unclassified and they share 1MiB/s of bandwidth. One big happy unclassified family. 🫢

subsystem blkio
limit /a 1024

Clients in the blkio /a group are limited to 1MiB/s β€” and no other clients can perform any I/O. At all. Sorry bestie, you're not on the list. πŸ’€

subsystem blkio
limit unclassified 256
limit /a   1024
limit /b/a 2048

Okay so here: the blkio group /a is allowed to transfer 1MiB/s, while /b/a gets 2MiB/s. Clients from other groups (like, say, /b, /z, /a/a, /b/z) are considered unclassified and they share 256KiB/s of bandwidth between them. Group project energy, but make it bandwidth. πŸ“


🧚 TUNING NOTES 🧚

Global I/O limiting is managed by the master server. Mount instances reserve bandwidth allocations from the master when they want to perform I/O to chunkservers.

Now β€” to avoid overloading the master under heavy traffic, mounts try to predict their future usage and reserve, all at once, all the bandwidth they'll need for the next renegotiation period (peep leil-master.cfg(5) for that one).

But here's the catch, and it's a real one: those reservations get wasted if the traffic at a given mount instance suddenly drops. Like, you booked the whole club and nobody showed. 😭

The ratio of bandwidth being wasted due to this phenomenon shouldn't exceed fsp/b, where:

f is the frequency of sudden traffic drops in the whole installation (in 1/s)
s is the average size of such drop (in KiB/s)
p is the renegotiation period (in s)
b is the bandwidth limit (in KiB/s)

And this applies to each group separately, because groups reserve their bandwidth independently from each other. Independent queens. πŸ‘‘


πŸ› REPORTING BUGS πŸ›

Found a bug? Report it to the GitHub repository over at https://github.com/leil-io/leilfs, as an issue. That's the whole process. Go off. πŸ”₯


Copyright 2008-2009 Gemius SA

Copyright 2013-2019 Skytechnology sp. z o.o.

Copyright 2023-2024 Leil Storage OÜ

LeilFS is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.

LeilFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with LeilFS. If not, see http://www.gnu.org/licenses/.


🌈 SEE ALSO 🌈

  • leil-master.cfg(5) β€” go read it, it's the whole renegotiation period connection, you'll get it. πŸ¦‹

And that's the page, bestie! πŸ’… Sourced from the LEIL-GLOBALIOLIMITS.CFG(5) manual, dated 1980-01-01 β€” yes, that date is real, and yes, it's iconic in a deeply unhinged way. Now go forth and limit some I/O. Periodt. βœ¨πŸŽ€

πŸ“¦ where this page comes from