Skip to main content

Class priority and export groups

A Storage Class definition has two settings that decide nothing about where chunks are stored. The priority decides which class governs a chunk that several files share. The export group decides which mounts may assign the class to their files. This page describes both settings, and the admin-only flag that works alongside the export group. Label expressions and matching covers how a class's placement rules are read and matched. How policies are applied covers how objects get a class at all.

Priority picks the class governing a shared chunk​

Snapshots make one chunk belong to several files at once. Those files can have different Storage Classes. The chunk is stored once, so a single class has to decide how the chunk is kept. The Master Server picks that class from the classes of all the files that the chunk belongs to. The class with the highest priority takes precedence. Priority is a number in the class definition, from 0 to 4294967295. Unless it is set, the priority is 0.

When the priorities are equal, the tie is broken by what the candidate classes require, in this order:

  1. The higher redundancy across the class's KEEP and ARCHIVE definitions, counted in copies, with an Erasure Coding format counted as its parity parts plus one.
  2. An Erasure Coding format in ARCHIVE, over none.
  3. Labels in KEEP or ARCHIVE, over none.
  4. An Erasure Coding format in TRASH, over none.
  5. Labels in TRASH, over none.
  6. The higher class ID.

The choice is not made once. The Master Server makes the choice again whenever the set of files that share the chunk changes. That happens when a snapshot is taken, when one of the files is deleted, or when one of the files is moved to a different class. The Master Server also makes the choice again for every chunk that the chunk loop visits. A raised class priority therefore applies to the existing shared chunks in the background, within one pass. The chunks are then checked again against the class that now governs them, the same way as after any class change.

Priority decides nothing else. It plays no part for a chunk that belongs to a single file, no part in matching Chunkservers to labels, and no part in the order of repairs, which has queues of its own.

This selection was introduced in MooseFS 4.57.0. Before that, a chunk shared by files in different classes was assigned one predefined class instead of any of the classes of those files.

Export groups decide which mounts may assign a class​

Every Storage Class belongs to exactly one export group. The groups are numbered 0 through 15. A class belongs to group 0 unless the definition says otherwise. An export entry in mfsexports.cfg may in turn have the sclassgroups option. The option lists the groups that the entry's clients may use. The set is given to the client's session when the mount registers. An entry without the option allows all 16 groups. sclassgroups=- allows none. The mfsexports.cfg reference covers the option's syntax. Export rule evaluation covers which entry admits a given mount.

The set restricts one operation: a client's request to set or exchange the Storage Class of a file or directory. When the target class's export group is outside the session's set, the Master Server refuses the request with a permission error (EPERM). The object keeps the class that it had.

Everything else is unrestricted. The restriction hides nothing. Listing the class definitions works from any mount, whatever its groups. The restriction does not affect the data. A mount reads and writes a file of a class outside its own set the same way as any other file. The restriction also does not affect class assignment that the client did not request, whatever group the assigned classes are in. A new file still gets the class of its directory. A pattern still assigns what it matches. A snapshot still has the class of its source. The restriction has one consequence for inherited files. When a user moves such a file to a class from an allowed group, the user cannot move the file back, because the original class's export group is outside the session's set.

Export groups were also introduced in MooseFS 4.57.0. When metadata from before that release is upgraded, the numeric classes 1 through 9 go into the groups of the same number. Every other class goes into group 0.

The admin-only flag is a second, separate restriction​

A class can be marked admin only in its definition. Files and directories then enter and leave such a class only through a session admitted by an export entry with the admin option. For any other session, a request to set an object to an admin-only class, or to move an object off such a class, is refused with the same permission error. In a recursive operation, such objects are skipped and counted as not permitted. The operation continues with the remaining objects.

The same admin option also allows managing class definitions in the first place. Creating, changing, renaming, and deleting classes is refused without the option. Listing the definitions works without it.

The two restrictions are independent. The admin flag does not bypass export groups. A session admitted with admin still has the sclassgroups set of its export entry. Setting a class from outside that set is refused even for such a session. An export entry can also forbid the whole operation for its clients with disable=setsclass. That option refuses every class assignment, regardless of groups and flags.