LEIL-GOALS.CFG(5)

📦 version 5.12.0, in nixpkgs unstable

💅 LEIL-GOALS.CFG — like, the replication goals config file, bestie (section: NAME)

okay so real talk, this is leil-goals.cfg(5) — the file that holds all the definitions of your replication goals. it's giving "control room energy" and honestly? iconic. 🎀

✨ DESCRIPTION ✨

The file leil-goals.cfg contains definitions of the replication goals. that's it, that's the vibe. no cap. 🦋

🌸 SYNTAX 🌸

the syntax is literally:

id name : $type { label ... }

id name : label ...

and the # character starts comments — so go off in the margins, nobody's judging. 💅

👑 DETAILS 👑

okay so here's the tea: there are 40 replication goals, with ids between 1 and 40, inclusive. every file stored on the filesystem refers to some goal id, and it gets replicated according to the goal currently associated with that id. so like, the goal you pick today can change the whole situation tomorrow. main character energy fr fr.

By default, the first five goals are defined: goal 1 means one copy on any chunkserver, goal 2 means two copies on any two chunkservers and so on, until 5 — which is the maximal default number of copies. slay. so out of the box you're covered. 💖

The purpose of leil-goals.cfg is to override this behavior, when desired. The file is a list of goal definitions, each consisting of id, name and a list of labels. The maximal length of this list is 40 labels. forty. that's a lot of labels babe, use them wisely. ✨

Let's break down the pieces:

  • id — indicates the goal id to be redefined. If some files are already assigned this goal id, their effective goal will change. so like, heads up: you're not just editing a label, you're editing their destiny. 😭
  • name — a human readable name used by the user interface tools (leil-setgoal(1), leil-getgoal(1)). name can consist of up to 32 alphanumeric characters: a-z, A-Z, 0-9, _. no spaces, no emoji, sorry bestie, the alphabet is the limit. 🫶

🌈 the goal types

type specifies goal type — currently supported types are:

  • std — for each file using this goal and for each label, the system will try to maintain a copy of the file on some chunkserver with this label. classic, reliable, never misses. 👑
  • ec(K,M) — for each file using this goal, the system will split the file into K + M parts (K data parts and M parity). For reading, any K of the parts are necessary. If labels are specified, parts will be kept on chunkservers with these labels. Otherwise, default wildcard labels will be used. K can be in range from 2 to 32 and M from 1 to 32. erasure coding girlies rise up 🔥

If the type is unspecified, it is assumed to be std. default behavior, we love to see it.

🎀 the labels

The list of labels is a list of chunkserver labels as defined in leil-chunkserver.cfg(5). label can consist of up to 32 alphanumeric characters: a-z, A-Z, 0-9, _. same rules as name, matchy matchy. 💅

One label may occur multiple times — in such case the system will create one copy per each occurrence. so if you write it three times, you get three copies. the way that works is genuinely so satisfying. The special label _ means "a copy on any chunkserver". wildcard bestie. 🦋

⚠️ Note that changing the definition of a goal in leil-goals.cfg affects all files which currently use given goal id. yes, ALL of them. not a drill. this is the part where you double-check before you commit, okay? 🙈

⭐ EXAMPLES ⭐

Some example goal definitions:

3 3 : _ _ _   # one of the default goals (three copies anywhere)

8 not_important_file : _   # only one copy

11 important_file : _ _

12 local_copy_on_mars : mars _ # at least one copy in the Martian
datacenter

13 cached_on_ssd : ssd _

14 very_important_file : _ _ _ _

15 first_ec : $ec(3,1)

16 ec32_ssd : $ec(3,2) { ssd ssd ssd ssd ssd } # all parts on ssd

17 ec53_mixed : $ec(5,3) { hdd ssd hdd _ _ _ _ _ } # two parts on hdd
and one part on ssd

mars datacenter. MARS. the ambition is unmatched, honestly obsessed. 🔥

🧚 SNAPSHOT FILES 🧚

Snapshot shares data with the original file until the file receives modification and diverges from the snapshotted version. If some snapshot has different goal than its original file, any shared data are stored according to the goal with higher id of the two.

so when two goals are fighting over the same data, the bigger id wins. eldest sibling rules. 💀

💀 REPORTING BUGS 💀

found a bug? Report bugs to the GitHub repository https://github.com/leil-io/leilfs as an issue. don't be shy, the maintainers want to hear it fr fr. 🫶

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/.

(no warranty means no warranty babe, read the license, it's literally the law 😭)

🌟 SEE ALSO 🌟

  • leil-master.cfg(5)

and that's the whole page, bestie! 🎀 this one dropped 1980-01-01 and it's still serving — it's from the LEIL-GOALS.CFG(5) manual, mwah, go configure your goals, ily, bye! 💖✨🦋

📦 where this page comes from