mfsscadmin(1)

📦
version 4.59.2 · 3 versions
, in arch rolling, nixos 26.05, nixpkgs unstable, ubuntu stonking

👑 mfsscadmin(1) — the MooseFS storage class administration tool 👑

okay bestie, buckle up, because mfsscadmin is the whole set of tools that runs the storage-class side of your MooseFS cluster, and she is iconic. This is part 1 of her manual page, and it's giving encyclopedia but make it cute. 💅✨

🎀 NAME 🎀

mfsscadmin — MooseFS storage class administration tool. that's it, that's the name, she said what she said. 🫶

✨ SYNOPSIS ✨

here's how you actually summon each one of these bad girls, fr fr:

mfscreatesclass [-?] [-M MOUNTPOINT] -K KEEP_LABELS [-c description] [-p
priority] [-g export_group] [-a admin_only] [-m labels_mode] [-o
arch_mode] [-C CREATE_LABELS] [-A ARCH_LABELS [-d arch_delay] [-s
min_file_length]] [-T TRASH_LABELS [-t min_trashretention]]
SCLASS_NAME...
mfsmodifysclass [-?] [-M MOUNTPOINT] [-c description] [-p priority] [-g
export_group] [-a admin_only] [-m labels_mode] [-o arch_mode] [-C
CREATE_LABELS] [-K KEEP_LABELS] [-A ARCH_LABELS] [-d arch_delay] [-s
min_file_length] [-T TRASH_LABELS] [-t min_trashretention]
SCLASS_NAME...
mfsdeletesclass [-?] [-M MOUNTPOINT] SCLASS_NAME...
mfsclonesclass [-?] [-M MOUNTPOINT] SRC_SCLASS_NAME DST_SCLASS_NAME...
mfsrenamesclass [-?] [-M MOUNTPOINT] SRC_SCLASS_NAME DST_SCLASS_NAME
mfslistsclass [-?] [-M MOUNTPOINT] [-l] [-i] [SCLASS_NAME_GLOB_PATTERN]
mfsimportsclass [-?] [-M MOUNTPOINT] [-r] [-n filename]

🌸 DESCRIPTION 🌸

so, what is this? it's a whole lil squad of tools for managing MooseFS storage classes. and what's a storage class, you ask? 💭 it's basically the redundancy policy of your cluster — like, the rules that say how your data gets duplicated and where it physically lives. you define them here, and then later you slap them onto particular MooseFS objects (files or folders) using the mfssclass tools — see mfssclass(1) if you wanna go down that rabbit hole. 🐇

a storage class is a named set of labels expressions plus some other options, lowkey. the labels expression is the part that spells out three things:

  • the redundancy format — either copies or erasure-coding (EC)
  • the redundancy level — either the number of copies (from 1 to 9) or the number of data plus parity parts (4+n or 8+n), depending on which redundancy format you picked
  • the storage policy — which, through the use of labels, says exactly which chunkservers are allowed to physically store the data assigned to that particular storage class

now let's meet the squad, one icon at a time: 👑

  • mfscreatesclass creates a new storage class with the options described below, and names it SCLASS_NAME. you can hand her more than one name, too — if you do, she'll create multiple storage classes with the same definition. no cap. 🌈
  • mfsmodifysclass changes the given options in the class or classes indicated by the SCLASS_NAME parameter(s). glow-up time. ✨
  • mfsdeletesclass removes the class or classes indicated by the SCLASS_NAME parameter(s). but heads up bestie — if any of those classes is not empty (i.e. it's still being used by some MooseFS objects), it will not be removed, and the tool will return an error and print an error message. empty classes will be removed in any case, though. 💀
  • mfsclonesclass copies the class indicated by SRC_SCLASS_NAME under a new name provided with DST_SCLASS_NAME. twin energy. 👯
  • mfsrenamesclass changes the name of a class from SRC_SCLASS_NAME to DST_SCLASS_NAME. rebranding, slay. 🎀
  • mfslistsclass lists all the classes. simple. iconic. 🤍
  • mfsimportsclass imports storage classes definitions from stdin or a file, and creates them. the input format should be identical to mfslistsclass -l output. copy-paste meal. 🍽️

💖 OPTIONS 💖

okay this is the part everyone scrolls to, so let's go, one bullet at a time, no skips, no summaries, periodt:

  • -C — optional parameter that tells the system to which chunkservers, defined by the CREATE_LABELS expression, the chunk should be first written just after creation. if this parameter isn't provided for a class, the KEEP_LABELS chunkservers will be used instead. 🌱
  • -K — mandatory parameter (yes girl, mandatory, you cannot skip her) that tells the system on which chunkservers, defined by the KEEP_LABELS expression, the chunk(s) should be kept always — except for special conditions like creating, archiving, and deleting (moving to Trash), if defined. 🔒
  • -A — optional parameter that tells the system on which chunkservers, defined by the ARCH_LABELS expression, the chunk(s) should be kept for archiving purposes. the system starts treating a chunk as archive when the atime/mtime/ctime (as set by -o) of the file it belongs to is older than the number of hours specified with -d. see also the ARCHIVE BEHAVIOUR section below. 📦
  • -d — optional parameter that defines after how much time from atime/mtime/ctime (as set by -o) a file (and its chunks) is treated as archive. minimum unit is hours, default is 24, and for value formatting see TIME. ⏰
  • -o — optional parameter that defines archive flags. C — ctime, M — mtime, A — atime, R — reversible, F — fastmode, P — per chunk. default is C. see the ARCHIVE BEHAVIOUR section below for the deets. 🚩
  • -s — optional parameter that defines the minimum file length in bytes that can be archived. default is 0. 📏
  • -T — optional parameter that tells the system on which chunkservers, defined by the TRASH_LABELS expression, the chunk(s) of files in Trash should be kept. see also -t. 🗑️
  • -t — optional parameter that defines how much time in Trash must be left for the system to actually use the schema defined in -T for a chunk. minimum unit is hours, default is 0, and for value formatting see TIME. ⌛
  • -c — optional parameter that defines a class description, for user's convenience (a string, maximum length is 255 bytes). a lil caption for your class, if you will. 📝
  • -p — optional parameter that defines a class priority. default is 0. see the STORAGE CLASSES PRIORITY section. 🥇
  • -g — optional parameter that defines a class export group. possible values are 0 to 15, default is 0. see mfsexport.cfg(5) for the explanation. 🎁
  • -a — can be either 1 or 0, and indicates if the storage class is available to everyone (0) or admin only (1). 🔐
  • -m — label mode used. possible values are l (or L, loose, Loose, LOOSE) for LOOSE mode, d (or D, std, Std, STD) for STANDARD mode, and s (or S, strict, Strict, STRICT) for STRICT mode. if no mode is defined, STANDARD mode is assumed. the behaviour of label modes is described below in the LABEL MODES section. 🏷️
  • -l — list also definitions, not only the names of existing storage classes. the director's cut. 🎬
  • -i — case insensitive storage class name matching. your lowercase typing is safe with her. 🙈
  • -r — replace (overwrite) existing classes when importing storage classes. out with the old, in with the new. 🔄
  • -n — use the provided filename as the source of storage classes definitions for importing, instead of stdin. 📂
  • -M — MooseFS mount point. doesn't need to be specified if a tool is run inside a MooseFS mounted directory, or if MooseFS is mounted in /mnt/mfs/. 🗺️
  • -? — displays a short usage message. the "help me bestie" button. 🆘

🧚 NOTES 🧚

🔥 LABELS EXPRESSIONS 🔥

okay so this is the part where it gets real, and honestly it's giving main character energy, so let's focus. ✨

labels are letters (A-Z — that's 26 letters, exactly). they get assigned to chunkservers, and each chunkserver can have multiple labels — up to 26 of them. labels are defined in the mfschunkserver.cfg file, so go read that manpage if you need the full tea. ☕

a labels expression is a set of subexpressions separated by commas. for full copies, each subexpression specifies the storage schema of one copy of a file. and each subexpression can be:

  • an asterisk *, or
  • a label schema

a label schema can be one label, or an expression with sums, multiplications, negations and brackets:

  • sum means a file can be stored on any chunkserver matching any element of the sum (logical or)
  • multiplication means a file can be stored only on a chunkserver matching all the elements (logical and)
  • asterisk means any chunkserver
  • negation means any chunkserver but the one matching the negated subexpression

and here's a lil glow-up tip: identical subexpressions can be shortened by adding a number in front of one instead of repeating it a number of times. work smarter, not harder. 💅

for EC labels expressions, the whole thing starts with an @ sign, followed by a number of data parts, then a + sign, then a number that says how many parity parts the chunk should have. the possible numbers of data parts are 4 or 8. the possible numbers of parity parts are 1 (CE version) or 1 to 9 (PRO version). so, for example, @4+1 means EC with 4 data parts and 1 parity part, and @8+3 means EC with 8 data parts and 3 parity parts. 🧮

if the number of data parts is omitted, then the master uses the default value defined by DEFAULT_EC_DATA_PARTS — see mfsmaster.cfg (5). in that case @2 means @8+2 or @4+2. then, a maximum of two subexpressions can follow, separated by commas. if only one is present, it defines where all the parts should be kept. if both are present, the first subexpression defines where the data parts should be kept, and the second subexpression defines where the parity parts should be kept. 📚

a labels expression can be either a regular labels expression or an EC labels expression — meaning an EC labels expression cannot be a subexpression. EC labels expression can only be used in place of ARCHIVE_LABELS or TRASH_LABELS in the storage class definition, while a regular labels expression can be used in any place. not interchangeable, bestie, that's the rule. 🚫

at the end of each label expression, one or two pieces of extending information can be added, divided with a special separator:

  • the first possible extension is the distinguish extension, and its separator is the slash (/) sign
  • the second is the labels mode override, and this extension is separated by a colon (:) sign

the distinguish extension can be a list of labels, or one of the following special strings:

  • [IP] or [I] — distinguish by IP number
  • [RACK] or [R] — distinguish by RACK, as defined in topology, see mfstopology.cfg (5)

if present, the distinguish part lets the system know that it should try to distribute full copies so that each copy is either on a different label from the list, or on a chunkserver with a different IP address, or from a different rack. for EC, the distinguish part is currently ignored. 🙈

NOTICE! if CHUNKS_UNIQUE_MODE is defined in mfsmaster.cfg to a value other than 0, it will override any distinguish setting in storage classes. for more information about this parameter, refer to the mfsmaster.cfg (5) manual. 💀

the labels mode override extension can be one of three characters:

  • d (alternatively D, or in string form std or Std or STD)
  • s (alternatively S, or in string form strict or Strict or STRICT)
  • l (alternatively L, or in string form loose or Loose or LOOSE)

and they mean that the STANDARD, STRICT or LOOSE label mode, respectively, should be applied only to this one labels expression. for the explanation about label modes, see the LABEL MODES section. 🏷️

one or both extensions can be present for each labels expression, and each has to start with their separator. if both are present, the order has to be kept — i.e. the distinguish extension has to be first, and the label mode extension needs to be second. do not switch them, she will notice. 👀

Examples of labels expressions:

  • A,B — files will have two copies, one copy will be stored on chunkserver(s) with label A, the other on chunkserver(s) with label B
  • A,* — files will have two copies, one copy will be stored on chunkserver(s) with label A, the other on any chunkserver(s)
  • A,!A — files will have two copies, one copy will be stored on chunkserver(s) with label A, the other on any chunkserver(s) that doesn't have the label A
  • *,* — files will have two copies, stored on any chunkservers (different for each copy)
  • AB,C+D+E — files will have two copies, one copy will be stored on any chunkserver(s) that has both labels A and B (multiplication of labels), the other on any chunkserver(s) that has either the C label or the D label or the E label (sum of labels)
  • A,B[X+Y],C[X+Y] — files get three copies: one lands on any chunkserver(s) with the A label, the second on any chunkserver(s) that has the B label and either the X or the Y label, and the third on any chunkserver(s) that has the C label and either X or Y 💖
  • 2A — literally just the same thing as A,A ✨
  • A,3BC — this is the same as A,BC,BC,BC, no cap
  • 2 — equivalent to 2* which is equivalent to *,* (we love a shortcut 🎀)
  • 3*/[IP] — files get 3 copies, and every single copy has to sit on a chunkserver with a different IP address 🌸
  • A,B/[RACK] — files get two copies: one lives on chunkserver(s) with label A, the other on chunkserver(s) with label B in a different rack than the other copy 🦋
  • S,H,H/ABX-Z — three copies: one on a server with label S, two on servers with label H, but each copy has to be on a server with a different label drawn from the set A, B, X, Y, Z
  • @4+1 — files are kept in EC format, with 4 data parts and 1 parity part 💅
  • @8+3 — EC format again, 8 data parts and 3 parity parts
  • @2 — EC format, default number of data parts, 2 parity parts
  • @4+3,Z — EC format, 4 data parts and 3 parity parts, all of them on chunkservers with label Z 👑
  • @2,A(X+Y) — EC format, default number of data parts, 2 parity parts, and all the parts get kept on chunkservers with label A and either X or Y
  • @3,S,H — EC format; the default number of data parts goes on chunkservers with label S, and 3 parity parts go on chunkservers with label H
  • AB,AC:l — copies format here: one copy on a server with labels A and B, the second on a server with labels A and C, and the behaviour of all this should be LOOSE
  • @4+2,X,Y:s — EC format: 4 data parts on servers with label X, 2 parity (checksum) parts on servers with label Y, and the behaviour here should be STRICT
  • 2A/[IP]:s — 2 copies, both on servers with label A, but each server must have a different IP, and the behaviour when accounting for labels should be STRICT

🌈 LABEL MODES 🌈

okay so this part is Important™ — it's all about what happens when the labels requirement of a storage class cannot actually be met. Like: there's no space on all the servers that have the needed labels, or there just aren't enough servers with those labels, or the servers with those labels are all busy 😭 The real question is whether the system should go make chunks on other servers (the ones with non-matching labels) or just… not. And that decision? The user has to make it. No autopilot, bestie.

There are 3 modes of operation: STANDARD, LOOSE and STRICT. They behave a lil bit differently depending on whether a chunk is stored in copies format or EC format, because those two formats are built different — different nature, different algorithms, you know how it is 💅

For copies format, here's how the 3 modes move:

In STANDARD mode, if servers are overloaded the system will wait for them. But if there's no space available, it'll use other servers instead and then replicate the data over to the correct servers once that becomes possible. What that means: if some servers sit in a busy state for a long time, it might be impossible to create new chunks with certain storage classes at all, and endangered (undergoal) chunks from those classes are at higher risk of being completely lost due to delayed replications 💀

In STRICT mode, while a new file is being written, the system will return an error (ENOSPC) if there's no space available on the servers marked with the labels specified for chunk creation. It'll still wait for overloaded servers. Undergoal replications will not be performed if there's no space on servers with labels matching the storage class. Which means… high risk of losing data if servers with some labels are permanently filled up with data! 🚨

In LOOSE mode, the system will immediately use other servers when servers are overloaded or when there's no space on servers, and it'll replicate data to the correct servers as soon as that becomes possible. No delay, no error on file creation, and undergoal replications are always done as soon as possible ✨

Here's the tea on all the modes for chunks stored in copy format:

  • CREATE - OVERLOADED — STANDARD: WAIT, STRICT: WAIT, LOOSE: WRITE ANY
  • CREATE - NO SPACE — STANDARD: WRITE ANY, STRICT: ENOSPC, LOOSE: WRITE ANY
  • REPLICATE - OVERLOADED — STANDARD: WAIT, STRICT: WAIT, LOOSE: WRITE ANY
  • REPLICATE - NO SPACE — STANDARD: WRITE ANY, STRICT: NO COPY, LOOSE: WRITE ANY

And for chunks stored in EC format, the 3 modes go like this:

In general, chunks only get converted from copy format to EC format if there are enough servers in the system to safely store all the parts of the EC format. For the EC @N+X format, where N is the number of data parts and can be either 4 or 8, and X is the number of parity/checksum parts and can be equal to 1 (CE version) or any number from 1 to 9 (PRO version), the general requirements are:

  • at least N+2X chunk servers to convert new chunks from copy format to EC format
  • at least N+X chunk servers to keep chunks that are already in EC format still in this format
  • if there are less than N+X servers, all chunks will revert to copy (KEEP definition) format.

In LOOSE mode, the system will try to use the servers matching the label expression defined in the storage class first — but if not enough servers with "correct" labels are available (because they're busy, or have no space, or are just straight up not defined), it'll use any available chunk server regardless of label. So the N+2X and N+X numbers get calculated from all available chunk servers whenever the system is deciding what format to keep a chunk in. Also: when one part of a chunk in EC format becomes unavailable or corrupted, restoring that part will also be done on any available server, if a server with "correct" labels can't currently be used. 🫶

It's important to remember: if not enough servers with "correct" labels are available for a chunk in LOOSE mode, the system may use however many it wants of the "other" chunk servers — not just the minimal amount that's missing from the "correct" number of servers. Like, it's not being polite about it 💀

In STRICT mode, the system will only use servers matching the label expression defined in the storage class. So only available or short-term busy servers matching the defined label expression get used for calculating N+2X and N+X when the system decides what format to keep a chunk in. When one part of a chunk in EC format becomes unavailable or corrupted, restoration of that part can only happen on a server with the "correct" label; if such a server is unavailable long term (i.e. it's not available outright, or only temporarily busy), this automatically means the chunk needs to be reverted to keep format anyway. And if the missing part happens to be a parity/checksum part, the chunk will just revert to copy format using all available data parts. If a data part is missing, it'll be restored to a chunk server hosting another part of the same chunk — which is not allowed under normal circumstances — and then the conversion to copy format will follow immediately. yeah. that happened.

In STANDARD mode, the system behaves like STRICT mode when it needs to decide whether to convert a new chunk from copy format to EC format — meaning the N+2X in this step is calculated only from "correctly" labeled servers. But when it's deciding whether existing chunks need to be converted back from EC format to copy format, it looks at all available servers regardless of labels, so the N+X in this step is calculated from all available servers, just like in LOOSE mode. X. In case of missing parts, if it's not possible to restore them onto chunk servers with "correct" labels, the system will also adapt the LOOSE mode behaviour and try to use any available servers. (yes, that lone X. really is sitting there in the original and I'm not touching it 🙈)

Notice! When a chunk gets converted from copy format to EC format, the system first performs a "local split" operation — it picks one copy of the chunk and calculates all the EC parts necessary on the server occupied by that selected copy. Then those parts are moved to separate chunkservers matching the labels in the storage class definition for the EC mode being used. But temporarily, between the split and the "moving out" of the parts, they can be recorded on a "wrong" chunk server even in STRICT mode 😱 This is because of the mechanics of the "local split" operation. Nothing you did, bestie, it's just how it works.

⏰ TIME ⏰

For time variables, the value can be defined as a number of seconds or hours (integer), depending on the minimum unit of the variable, or as a time period in one of two possible formats:

first format: #.#T where T is one of: s-seconds, m-minutes, h-hours, d-days or w-weeks; fractions of the minimum unit get rounded to an integer value 🌸

second format: #w#d#h#m#s — any number of definitions can be omitted, but the remaining definitions must be in order (so #d#m is still a valid definition, but #m#d is not) 🚫 Ranges: s, m: 0 to 59, h: 0 to 23, d: 0 to 6, w is unlimited, and the first definition is also always unlimited (i.e. for #d#h#m, d will be unlimited).

If the minimum unit of a variable is larger than seconds, units below the minimum one will not be accepted. For example, a variable that has hours as a minimum unit will not accept s and m units. Soz.

Examples:

  • 1.5d is the same as 1d12h, is the same as 36h ✨
  • 2.5w is the same as 2w3d12h, is the same as 420h
  • 2w84h is not a valid time period (h is not the first definition, so it's bound by range 0 to 23) ❌

🌸 ARCHIVE BEHAVIOUR 🌸

Chunks get their archive flag set during the file maintenance loop, which means the time to archiving defined by the -d option is the minimum time that has to pass before the flag is set — not the exact time. So like, at least that long, maybe longer 💅

Default behaviour of the system: once a chunk has the archive bit set on, it IS NOT switched off even if atime/ctime/mtime changes — unless the R flag is set by option -o. Writing to a chunk will always switch its archive flag off. Always always.

Archive flags:

  • C — use the file's ctime to determine if the archive flag should be set on — this is the default flag ⭐
  • M — use the file's mtime to determine if the archive flag should be set on
  • A — use the file's atime to determine if the archive flag should be set on
  • R — reversible: if atime/mtime/ctime changes for a file, the system verifies whether the archive flag should be turned off for its chunks
  • F — fastmode: the chunk has its archive flag set to on as soon as possible, and whatever is defined with the -d option is disregarded 🏃‍♀️
  • P — "per chunk" mode: use the chunk's mtime to determine if the archive flag should be set on

Archive flag can be modified manually. See mfsarchive (1) 👑

Okay so real talk about the ARCHIVE state, because bestie everybody gets this twisted: ARCHIVE does not mean your chunks or files are somehow unavailable, blocked for writing, etc. 🚫 The ARCHIVE designation is only there to say "this data is already intended for long-term storage." Which is a whole different vibe from the KEEP state, where the data is 'hot' and can be changed frequently. 🔥 So the KEEP vs. ARCHIVE distinction exists purely so the system can define an appropriate physical way of storing this data. And from your point of view as a user? The file is equally accessible: identical permissions, name, and it's chilling in the same directory. ✨

Real-world example, since I know you want one: writing in EC mode may be slower, so we suggest you store 'hot' data (that's KEEP) using a copy, and then change it to EC format (by assigning ARCHIVE mode) after some time. 💅 Another one: automatic transfer of 'cold' data to older/slower/cheaper disks and chunkservers — using different labels. Iconic, honestly.

🌈 STORAGE CLASSES PRIORITY 🌈

So storage classes get assigned to files, but here's the plot twist: one chunk (which is one fragment of a file) can belong to many files, courtesy of the snapshot mechanism (go read mfssnapshots (1), iykyk). 🦋 And if one chunk belongs to many files with different storage classes, then like… one storage class has to be picked to specify how this chunk's copies should be kept in the system. No cap.

Up to MooseFS version 4.56.0, a predefined class was artificially assigned to such a chunk. 🙈 Currently one of the files' classes will be used, according to priorities assigned by the user — to be exact: the system will pick the class with highest priority out of all the files' classes. Periodt.

Example 1: there are 3 classes defined, bestie:

  • ClassA, with priority 100
  • ClassB, with priority 206
  • ClassC, with priority 1001

A chunk that belongs to 2 files, one in ClassA and the other in ClassB, will be stored according to the definition provided by classB (higher priority than ClassA).

A chunk that belongs to 3 files — one in ClassA, one in ClassB, one in ClassC — will be stored according to the definition provided by classC (higher priority than both ClassA and ClassB). Slay. 💖

Now, if two or more classes have the same priority, then the following factors get considered, in order of importance, to determine which class will be picked:

  • a class with higher redundancy level (RL) will be picked (maximum from each class's KEEP and ARCHIVE redundancy levels will be considered as this class's redundancy level)
  • a class that has EC format in ARCHIVE state will be picked over a class without EC
  • a class that uses labels for KEEP or ARCHIVE state will be picked over a class without labels
  • a class that has EC format in TRASH state will be picked over a class without EC
  • a class that uses labels for TRASH state will be picked over a class without labels
  • if none of the above conditions are used, a class with higher class id will be used

Example 2: there are 5 classes defined, all with the same priority (e.g. the default priority 0):

  • ClassA (id=1) has 3 copies in KEEP state (RL=2)
  • ClassB (id=2) has 2 copies in KEEP state and EC4+1 in ARCHIVE state (RL=1, has EC in ARCHIVE)
  • ClassC (id=3) has 2 copies in KEEP state, stored on labels X (RL=1, no EC in ARCHIVE, has labels in KEEP)
  • ClassD (id=4) has 2 copies in KEEP state, stored on labels Y (RL=1, no EC in ARCHIVE, has labels in KEEP)
  • ClassE (id=5) has 2 copies in KEEP state (RL=1)

There is also a class ClassF defined, which has a priority of 77 and 2 copies in KEEP state (RL=1).

Now watch this:

  • A chunk that belongs to files in classes: ClassA, ClassC and ClassE will be stored according to the definition of ClassA (highest RL). 👑
  • A chunk that belongs to files in classes: ClassB, ClassC will be stored according to the definition of ClassB (same RL, but ClassB has EC).
  • A chunk that belongs to files in classes: ClassC and ClassE will be stored according to the definition of ClassC (same RL, but ClassC has labels).
  • A chunk that belongs to files in classes: ClassC and ClassD will be stored according to the definition of ClassD (same RL, no EC, both have labels, so higher class ID is picked).
  • A chunk that belongs to files in 6 classes, from ClassA to ClassF, will be stored according to the definition of ClassF, because this one has higher priority than all the other classes (77>0).

And in a system with these 6 storage classes, classE will never be used for a chunk belonging to multiple files — it has the lowest possible priority (0) and no extra conditions to justify its choice (lowest existing RL, no EC and no labels). 😭 RIP classE, you just weren't it.

🎀 PREDEFINED STORAGE CLASSES 🎀

A new MooseFS instance will have the following classes predefined, bestie:

  • 2CP — only KEEP state defined, keep 2 copies on any labels (this is the default class for the / directory 🫶)
  • 3CP — only KEEP state defined, keep 3 copies on any labels
  • EC4+1 — in KEEP state, keep 2 copies on any labels, in ARCHIVE state, keep chunks in EC4+1 format on any labels, archive delay is 1 day and is calculated using file's ctime, files smaller than 512kiB will not be converted to EC format
  • EC4+2 — (pro only) in KEEP state, keep 3 copies on any labels, in ARCHIVE state, keep chunks in EC4+2 format on any labels, archive delay is 1 day and is calculated using file's ctime, files smaller than 512kiB will not be converted to EC format
  • EC8+1 — in KEEP state, keep 2 copies on any labels, in ARCHIVE state, keep chunks in EC8+1 format on any labels, archive delay is 1 day and is calculated using file's ctime, files smaller than 512kiB will not be converted to EC format
  • EC8+2 — (pro only) in KEEP state, keep 3 copies on any labels, in ARCHIVE state, keep chunks in EC8+2 format on any labels, archive delay is 1 day and is calculated using file's ctime, files smaller than 512kiB will not be converted to EC format

These classes are fully modifiable and deletable and can be replaced with your choice of classes. Freedom, we love to see it. ✨

🚨 Okay bestie, listen up, because this next part is legacy lore. Up to version 4.56.0 of MooseFS the predefined classes were different. The following information pertains to old MooseFS behaviour. In newer versions of MooseFS the classes mentioned below might exist as a result of an upgrade, but will behave exactly like any user-defined classes. This information is left here purely for informative reasons and will be removed from this manual page at some point:

(Behaviour up to version 4.56.0) "For compatibility reasons, every fresh or freshly upgraded instance of MooseFS has 9 predefined storage classes. Their names are single digits, from 1 to 9, and their definitions are * to 9*. They are equivalents of simple numeric goals from previous versions of the system. In case of an upgrade, all files that had goal N before upgrade, will now have N storage class. These classes can be modified only when option -f is specified. It is advised to create new storage classes in an upgraded system and migrate files with mfsxchgsclass tool, rather than modify the predefined classes. The predefined classes CANNOT be deleted."

💫 EXAMPLES 💫

Create a new storage class named "Class2Copies" with 2 copies. The first copy on one of chunkservers with label "A" and the second copy on one of chunkservers with label "B":

mfscreatesclass -K A,B Class2Copies

Create a new storage class named "Class3Copies". Freshly created chunks (-C) will be kept anywhere with 2 copies (2*). Soon after creation they will be kept (-K) in 3 copies: the first copy on one of chunkservers with label "A", the second copy on one of chunkservers with label "B" and the third on any chunkserver:

mfscreatesclass -C '2*' -K 'A,B,*' Class3Copies

Create a new storage class named "ClassEC4_1". Chunks will be created and kept (-K) anywhere in 2 copies (2*) for 24 hours from the file creation. Later they will be archived (-A) in EC4+1 format on any chunkserver:

mfscreatesclass -K '2*' -A '@4+1' ClassEC4_1

Modify the "ClassEC4_1" storage class to archive chunks after 48 hours from the file modification (not creation):

mfsmodifysclass -d 2d -o m ClassEC4_1

Modify the "Class3Copies" storage class to keep chunks on other chunkservers (LOOSE mode) if the ones with labels "A" and "B" are too busy (overloaded):

mfsmodifysclass -m l Class3Copies

🐛 REPORTING BUGS 🐛

Found a bug? Don't gatekeep it, bestie — report it to <bugs@moosefs.com>. 💌

Copyright (C) 2026 Jakub Kruszona-Zawadzki, Saglabs SA

This file is part of MooseFS.

MooseFS 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 2 (only).

MooseFS 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 this program; if not, see <https://www.gnu.org/licenses/>.

👀 SEE ALSO 👀

mfsmount(8), mfstools(1), mfssclass(1), mfsarchive(1), mfsmaster.cfg(5), mfschunkserver.cfg(5), mfstopology.cfg(5)

And that's the whole page, bestie! This was ripped straight from MooseFS version 4.59.2-1, dated May 2026, under the name mfsscadmin(1) — go forth and manage those storage classes like the main character you are. 💅✨🦋

📦 where this page comes from