Skip to main content

Glossary

This glossary defines the terms used throughout the MooseFS documentation. Each entry is a short definition. The linked pages own the full explanation. Terms are grouped by theme: cluster components, data and metadata, redundancy and placement, states, background processes, high availability, namespace features, Multilocations, interfaces and tools, and editions.

Find a term by its name​

Cluster components​

Chunkserver​

The component that stores file data in the form of chunks and serves read and write requests. The literature also calls such a component a storage node or a data node.

Client​

A machine that uses a MooseFS instance. The client contacts the Master Server for metadata operations and exchanges file data directly with Chunkservers. Most clients mount the file system using mfsmount, but mfsbdev and libmfsio reach an instance without a mount point. See Clients. Also used on: Client-side background work, Multiple mounts and parallel access, The client, The per-mount throughput ceiling, What the FUSE layer costs.

libmfsio​

A client library that gives a program POSIX-like calls (mfs_open, mfs_read, mfs_stat, and their neighbors) on a MooseFS instance, without FUSE and without a mount point. mfsbdev is built on libmfsio. See Client and mount. Also used on: The per-mount throughput ceiling, What the FUSE layer costs.

Master Server​

The central component of MooseFS. The Master Server manages metadata, coordinates file operations, and keeps the file system consistent, but does not store file content. The literature also calls this role a metadata server (MDS). See Master Server.

Leader Master Server (PRO)​

The active Master Server in a high-availability setup. If the Leader Master Server fails, a Follower Master Server takes over.

Follower Master Server (PRO)​

A standby Master Server that continuously synchronizes metadata from the Leader Master Server and stands ready to take over.

Master Server states (PRO)​

The state that a Master Server reports: LEADER, FOLLOWER, ELECT during a leader election, DEPUTY for read-only service, USURPER for a Follower set to take the Leader role back, and DUMMY while shutting down. In Community Edition, a Master Server reports MASTER. See Leader election and quorum. Also used on: Leader election, quorum, and the role of DNS.

Metalogger​

A supporting service that keeps a second copy of the metadata current by receiving every changelog line and downloading the Master Server's metadata dumps. The Metalogger never takes the Master Server's work over: recovery means starting a new Master Server from the metadata that the Metalogger holds.

MooseFS Block Device (mfsbdev)​

A Linux-only client that exposes a single file stored in MooseFS as a block device, so applications can use it like a physical disk or partition.

MooseFS Mount (mfsmount)​

A filesystem mount program, that communicates with the cluster over MooseFS protocol and exposes a POSIX-compatible filesystem using the FUSE library to the operating system via a mountpoint.

MooseFS protocol​

The binary protocol that every MooseFS component speaks to every other component over TCP. The name of a command says who talks to whom: CLTOMA_FUSE_READ_CHUNK travels from a client (CL) to the Master Server (MA). The literature calls this protocol a wire protocol. See The protocol the modules speak.

Windows Client (PRO)​

A native MooseFS file system driver for Microsoft Windows that communicates with the cluster over the MooseFS protocol. See Windows Client.

Data and metadata​

Block​

A 64 KiB unit within a chunk and the unit of integrity checking. Each block carries a checksum that Chunkservers verify to detect corruption. Also used on: Chunkserver memory, Scrubbing and CRC verification, Small files, The chunk lifecycle.

Chain-like write​

The way MooseFS writes multiple copies: the client sends data to one Chunkserver, which stores the data and forwards it to the next Chunkserver in the chain. The literature also calls this way of writing chain replication. See The write path.

Changelog​

A file (changelog.*.mfs) in which the Master Server records every metadata operation between metadata dumps. Every line is also broadcast as it is written, to each Metalogger and, in the PRO Edition, to each Follower Master Server. Also used on: Changelogs, dumps, and the recovery point, The metadata engine.

Chunk​

A fragment of a file, up to 64 MiB, stored on Chunkservers. A chunk is the unit of placement and of replication. A chunk stored in Erasure Coding (EC) format is placed and replicated part by part. Also used on: Allocation and space selection, Chunkserver memory, From creation to the first chunk, The chunk lifecycle, What the class promises and what the chunks do.

Chunk version​

The number that the Master Server gives a chunk and raises on every write, truncation, or repair that may leave a stale copy behind. The chunk version is part of a chunk file's name, chunk_<id>_<version>.mfs. A copy whose version differs from the version that the Master Server holds does not count toward the chunk's redundancy. See Chunk versions and states.

Export​

A rule in mfsexports.cfg that defines which client IP addresses may mount which part of the namespace and with what options. See Session and export. Also used on: Class priority and export groups.

Inode number​

The number that identifies an object in the metadata for as long as the object exists. Renaming the object does not change the number. Changelog lines and the metadata tools name objects by it. Also used on: From creation to the first chunk, What metadata holds and what it costs in RAM.

Metadata​

The structure of the file system: file names, directories, permissions, ownership, and chunk locations. The Master Server manages the metadata and holds all of it in RAM. See Hardware requirements for Master Servers. Also used on: Master Server memory, Metadata ID, version, delay, and checksum, The metadata engine, What metadata holds and what it costs in RAM.

Metadata dump​

A complete copy of the metadata written to disk at one moment, kept as metadata.mfs.back and, after a clean shutdown, as metadata.mfs. A Master Server starts from a dump plus the changelog lines newer than it. The term for this file is dump: a snapshot in MooseFS is a copy of files, not of metadata. Also used on: Changelogs, dumps, and the recovery point, Metadata save states, The metadata engine.

Metafiles​

Virtual objects that the client answers to itself: .stats, .params, .oplog, .ophistory, .mooseart, .random, and .masterinfo. They are not real files and do not appear in directory listings. See Special files in a mount.

Minimum chunk cost​

The 72 KiB that a chunk holding any data costs in the size that the Master Server accounts for, however large the file inside the chunk is: 8 KiB of chunk header plus one whole 64 KiB block. On a workload of small files this figure, not the redundancy factor, decides how much of a cluster the data claims. See Small files.

MooseFS Meta (mfsmeta)​

A special mount (mfsmount -o mfsmeta) that shows the trash and the sustained files instead of the file system. MooseFS Meta is the way a file is recovered from the trash. Sustained files can only be listed there, not recovered. See Trash and sustained files.

Namespace​

The tree of directories and the names inside them, held by the Master Server as part of the metadata: the part that a client sees as the file system. Every object in the namespace is identified by an inode number. Also used on: Names: link, unlink, rename, and exchange, What metadata holds and what it costs in RAM.

Session​

The Master Server's record of a client that has registered, whether or not it mounted the file system. A disconnected client's session remains valid for the time set by SESSION_SUSTAIN_TIME in mfsmaster.cfg. See Session and export. Also used on: Client-side background work, Multiple mounts and parallel access.

Sparsification​

The Chunkserver's practice of dropping the leading and the trailing zeros of a 64 KiB block when the Chunkserver first writes the block, and of leaving a hole in the chunk file instead. HDD_SPARSIFY_ON_WRITE in mfschunkserver.cfg turns sparsification on or off. It is not the same thing as a sparse file, whose gaps are chunks that were never created. See Length, holes and truncation. Also used on: Small files.

Redundancy and data placement​

Archive flag​

A per-chunk flag that moves a chunk to the ARCHIVE state once the period that its Storage Class sets has passed since the file timestamp that the archiving mode selects. The period is given in hours and is 24 unless the class says otherwise. See Storage states. Also used on: Timestamps and what moves them.

Class priority​

A number in a Storage Class definition that decides which class governs a chunk shared by files of different classes: the highest priority wins. Class priority decides nothing about placement or the order of repairs. Introduced in MooseFS 4.57.0. Also used on: Class priority and export groups.

Copy (replica)​

A full duplicate of a chunk stored on a different Chunkserver. Copy-based redundancy is the alternative to Erasure Coding. The number of copies that a Storage Class requires is known in the literature as the replication factor. See Copy (replica). Also used on: Chunk versions and states, The chunk lifecycle.

Erasure Coding (EC)​

A redundancy format that splits a chunk into data parts and parity parts spread across Chunkservers, with lower storage overhead than full copies. A scheme is written @N+X: 4 or 8 data parts, and 1 to 9 parity parts in the PRO Edition (1 in Community Edition). The literature writes such schemes as k+m. See Erasure Coding. Also used on: Erasure Coding: part layout, Max cluster capacity.

Erasure Coding Chunkserver thresholds​

The two counts of Chunkservers, N+X and N+2X, that decide whether a chunk is stored in the @N+X format that its Storage Class asks for. The two counts decide the format only: a chunk on the wrong side of a threshold is converted, never refused and never lost. See Chunkservers needed for an Erasure Coding scheme. Also used on: Erasure Coding: part layout.

Erasure Coding part rotation​

The order in which the data parts of an EC chunk hold its bytes: the first 256 KiB on the first part, the next on the second, and so on. A read uses one Chunkserver per 256 KiB region that the read spans. The literature calls such an arrangement striping. See Erasure Coding: part layout.

Goal (deprecated)​

The deprecated predecessor of Storage Classes: a number saying how many copies of a file's chunks should exist. The word survives in the undergoal and overgoal chunk states shown by the GUI and CLI. See Goal (deprecated).

Label​

A single letter from A to Z assigned to a Chunkserver with the LABELS option in mfschunkserver.cfg. Labels are the elements of label expressions, which is how a Storage Class decides where chunks go. See Label. Also used on: Allocation and space selection, Label expressions and matching, Placement and policies, Preferred labels.

Label expression​

The placement rule of one storage state in a Storage Class. For copies the label expression is a comma-separated list of subexpressions that combine labels with operators, one subexpression per copy. For Erasure Coding the label expression takes the form @N+X, optionally followed by up to two comma-separated label subexpressions. The Erasure Coding format is allowed only in ARCHIVE and TRASH state definitions. Also used on: Label expressions and matching.

Labels mode (LOOSE, STANDARD, STRICT)​

Controls what happens when a label expression cannot be satisfied. LOOSE completes the chunk on non-matching Chunkservers, STANDARD does the same but waits when the servers that would complete the chunk are merely overloaded, and STRICT never uses a non-matching server. The mode belongs to a Storage Class and can be overridden for a single state definition. Also used on: Label expressions and matching.

MULTILAN​

Address remapping that keeps a client's traffic inside its own LAN, configured with MULTILAN_CLASSES. The Master Server gives the client a Chunkserver's address rewritten into the client's own address class. Unlike Multilocations, MULTILAN divides nothing: it only changes which address a client is given.

Patterns​

Rules that assign a Storage Class, a trash retention, and extra attributes to files and directories by matching their name, managed with mfspatadmin. A pattern applies when an object is created or renamed and overrides what the object would inherit from its parent directory. See Patterns. Also used on: How policies are applied, Names: link, unlink, rename, and exchange.

Preferred labels (mfspreflabels)​

A mount option (-o mfspreflabels=LABELEXPR) that makes the client sort a chunk's Chunkservers by an ordered list of label expressions. The order decides which copy is read and where a write is sent first. No chunk is placed or moved because of this option. Also used on: Preferred labels.

Raw space and user space​

Raw space is the space that the Chunkservers report for their disks, added up. User space, also called effective capacity, is the part of the raw space that ends up holding file data. Used raw space is the part of the raw space that stored data occupies once redundancy is counted in. Used raw space is the figure that a PRO license caps. See Raw space and user space. Also used on: Max cluster capacity.

Redundancy Level​

The number of simultaneous failures (a lost disk or a lost Chunkserver) that MooseFS tolerates for a chunk while still serving it. Three copies and EC 8+2 both give Redundancy Level 2. The GUI and mfscli label this value RL. See Redundancy Level.

Reserved disk space​

The free space that a Chunkserver holds back on each of its disks and never offers for chunks, set by HDD_LEAVE_SPACE_DEFAULT in mfschunkserver.cfg and 256 MiB unless changed. Reserved disk space is a different thing from the superuser reserve. See Raw space and user space.

Storage Class​

A named policy that defines, for each storage state, how many copies or EC parts of a chunk exist and on which Chunkservers those copies or parts are placed. See Storage Class. Also used on: How policies are applied, Placement and policies, Storage Class evaluation, What the class promises and what the chunks do.

Storage states (CREATE, KEEP, ARCHIVE, TRASH)​

The four lifecycle states of a chunk, each with its own placement definition in a Storage Class. CREATE covers a chunk while it is first written, KEEP a normal chunk, ARCHIVE a chunk that the class judged to have stopped changing, and TRASH a chunk of a deleted file. The states are a setting of the class, not a reading of the data. See Storage states. Also used on: Storage Class evaluation, What the class promises and what the chunks do.

Superuser reserve​

The amount of cluster space that RESERVE_SPACE in mfsmaster.cfg keeps for the superuser, 0 unless set. The superuser reserve comes off the available figure that a mount reports, so the reserve reads as space that an ordinary user cannot claim. The superuser reserve is unrelated to the space that a Chunkserver holds back on its own disks. See Raw space and user space.

Topology​

The definition of network "distance" between machines in mfstopology.cfg, used to keep traffic local by placing and reading replicas close to the client. The literature calls this mechanism rack awareness. See Topology and rack awareness. Also used on: Placement and policies, Topology mapping and distance.

Chunk, disk, and Chunkserver states​

Chunk matrix table​

The GUI and CLI table (Info tab) showing chunk counts by Expected Redundancy Level against Actual Redundancy Level. The chunk matrix table is the quickest way to judge the health of the data in the cluster. See Chunk versions and states and Cluster health parameters.

Chunks awaiting deletion​

Chunks of files already removed from metadata, counted until the chunk loop orders the chunk copies deleted and the Chunkservers report the space back. The GUI and mfscli both name this count pending deletion. Also used on: Deletion: from unlink to space returned.

Damaged disk​

A disk automatically excluded after exceeding the error tolerance (HDD_ERROR_TOLERANCE_COUNT errors within HDD_ERROR_TOLERANCE_PERIOD). All chunk copies that the disk held become unavailable, so an undergoal situation follows. See Disk error handling and disk removal.

Endangered chunk​

A chunk with no redundancy left: a single remaining copy, or exactly as many EC parts as are needed to read the chunk. Endangered chunks are repaired before any other chunk whose state calls for repair. See Self-healing. Also used on: Chunk versions and states, Replication priorities.

Internal rebalance (Chunkserver state)​

A Chunkserver moving chunks between its own drives to equalize their utilization, typically after a new disk is added. Internal rebalance runs at a background rate or in the high speed mode, which the Master Server treats like an overloaded Chunkserver. See Rebalancing.

Marked for removal (MFR)​

A disk state requested by prefixing the path of the disk with * in mfshdd.cfg: MooseFS replicates all chunks held on the disk elsewhere, so the hardware can be retired safely. See Chunkserver and disk recovery. Also used on: Disk error handling and disk removal.

Missing chunk​

A chunk with no remaining valid copy or EC part set. Missing chunks mean data loss and require immediate attention. See Self-healing. Also used on: Chunk versions and states.

Overgoal chunk​

A chunk with more copies than its Storage Class requires. MooseFS removes the surplus copies (or EC parts) automatically. See Goal (deprecated). Also used on: Chunk versions and states.

Overloaded (Chunkserver state)​

A Chunkserver that cannot accept more operations and has notified the Master Server. Normal scheduling resumes when the Chunkserver's load drops. See Allocation and space selection.

Stable chunk​

A chunk stored exactly as its Storage Class requires: the right number of copies, or a full set of EC parts. The other states in the chunk matrix table are read against the count of stable chunks. See Chunk versions and states.

Undergoal chunk​

A chunk with fewer copies, or fewer EC parts, than its Storage Class requires. MooseFS restores the missing copies or EC parts on its own. The data stays readable throughout. See Goal (deprecated). Also used on: Chunk versions and states.

Background processes​

Chunk loop​

The Master Server's periodic scan of all chunks, which schedules replication, deletion, format conversion, and state transitions. See The chunk loop and the file loop and Replication priorities. Also used on: Deletion: from unlink to space returned, Maintenance loops.

Chunk scrubbing​

The continuous background test of integrity and readability of stored chunks on Chunkservers. The test protects against silent data deterioration. The literature also calls this bit-rot protection. See Scrubbing and CRC verification. Also used on: Chunkserver housekeeping loops.

File loop​

The Master Server's periodic scan of all files: it applies each file's archive rule, records chunks left without a usable copy, audits the links between files and directories, and recounts the totals that the cluster reports. The GUI and mfscli report the file loop's progress as "Filesystem self-check". See The chunk loop and the file loop. Also used on: Maintenance loops.

Join​

The operation in which a Chunkserver rebuilds a full chunk in copy format from a complete set of EC data parts, read over the network. Join undoes what a local split did. See Erasure Coding.

Local split​

The operation in which a single Chunkserver turns a chunk copy that it holds into the EC parts that are missing and writes all of them on itself. Ordinary replication spreads them over other Chunkservers afterward. See Erasure Coding.

Rebalancing​

Moving chunks that already exist to equalize space usage, either between the drives of one Chunkserver or between Chunkservers across the cluster. Rebalancing between drives and rebalancing between Chunkservers are separate mechanisms with separate settings. See Rebalancing.

Recover​

The operation in which a Chunkserver rebuilds a missing EC part of a chunk from the parts that survive. Recover is the third Erasure Coding operation next to local split and join.

Replication limits​

Per-class caps on concurrent replications, set with CHUNKS_WRITE_REP_LIMIT and CHUNKS_READ_REP_LIMIT in mfsmaster.cfg. Each option takes five values, in this order: endangered chunks; every other chunk whose state calls for repair (one regular copy alongside copies marked for removal, marked for removal, unfinished EC, undergoal, wrong labels); rebalance between servers whose space usage is close; rebalance between servers whose usage is far apart; and replications caused by a client waiting to read or write. The boundary between the two rebalance classes is one and a half times ACCEPTABLE_PERCENTAGE_DIFFERENCE, measured between the source and the target. A single value is shorthand for the same value five times. See Replication priorities.

Self-healing​

The automatic return of a cluster to a healthy state after a failure of a disk, a Chunkserver, or a Master Server. For data, MooseFS re-replicates undergoal and endangered chunks and removes surplus copies. For metadata, the Leader Master Server makes a Follower whose checksum differs synchronize again (PRO). A Master Server that is gone is not covered: it is installed again and started from the metadata that a Metalogger or a Follower holds. See Self-healing.

High availability​

Emergency mode​

The state that the Master Server enters when it cannot save metadata to disk. The Master Server repeatedly retries saving metadata.mfs.emergency to a list of fallback paths. See Master Server problems.

High Availability (HA)​

Continuous access to data despite component failures. In MooseFS PRO, multiple Master Servers run in an active-passive configuration with automatic failover. In Community Edition, Master Server failover is manual. See No single point of failure.

Leader election​

The process by which Chunkservers vote for a candidate Master Server (ELECT) to become Leader. Promotion requires more than half of the votes. With Multilocations, votes are counted per location. See Leader election and quorum. Also used on: Leader election, quorum, and the role of DNS, The metadata engine.

Maintenance mode​

A per-Chunkserver state telling the Master Server that the Chunkserver is expected to be temporarily unavailable. Replication and rebalancing for its chunks are suppressed instead of triggering recovery. See Maintenance mode. Also used on: Disk error handling and disk removal.

Quorum​

The majority required for the cluster to elect and keep a Leader Master Server. Losing quorum halts leader election until enough voters reconnect. See Leader election and quorum. Also used on: Leader election, quorum, and the role of DNS.

Rolling upgrade​

Upgrading a cluster component by component while the cluster keeps serving data. In Community Edition the Master Server cannot be upgraded without a restart. See Rolling upgrade.

Split-brain protection​

A Master Server check that halts the cluster when too large a share of the registered Chunkservers becomes unreachable at once. The check prevents two sides of a network partition from serving conflicting data. See Leader election and quorum.

Temporary maintenance mode​

The maintenance mode entered automatically when a Chunkserver disconnects gracefully. CS_TEMP_MAINTENANCE_MODE_TIMEOUT limits how long this mode lasts (default 30 minutes). See Maintenance mode.

Namespace and file management​

Access Control Lists (ACLs)​

POSIX ACLs for granular permission management beyond owner/group/other, supported on MooseFS mounts. See Access Control Lists.

Admin-only storage class​

A Storage Class marked in its definition so that objects enter and leave the class only through a session admitted by an export entry carrying the admin option. This restriction is separate from storage class groups. Also used on: Class priority and export groups.

Copy-on-write (CoW)​

The algorithm behind snapshots. The snapshot shares the original chunks. A chunk is duplicated only when it is later modified. See Snapshot. Also used on: Snapshot copy-on-write semantics, The life of a file.

Disables​

The disable= export option that blocks selected file system operations (for example unlink, chown, snapshot) for clients matching an export rule.

Extended attributes (xattrs)​

Standard POSIX name-value metadata attached to files, supported by MooseFS and held by the Master Server in records of its own. See Extended and extra attributes.

Extra attributes (eattr)​

MooseFS-specific per-object flags such as immutable, appendonly, and undeletable, distinct from POSIX extended attributes. See Extended and extra attributes. Also used on: How policies are applied, Names: link, unlink, rename, and exchange.

File length, size and realsize​

The three figures that MooseFS keeps for the space that a file or a directory tree takes, printed by mfsdirinfo and settable as separate quota limits. length is the sum of the file lengths that applications wrote. size is the space that those files occupy in chunks. realsize is size scaled by the redundancy of each file's Storage Class. See Raw space and user space. Also used on: Length, holes, and truncation.

File locking​

Advisory locks coordinated cluster-wide by the Master Server, in two families that do not conflict with each other: BSD locks (flock) on a whole open file, and POSIX record locks (lockf) on a byte range. See File locking.

Global Trash​

A configurable space where deleted files are kept for the trash retention period before final removal. Recovery goes through the mfsmeta mount. See Trash and sustained files. Also used on: Deletion: from unlink to space returned, Trash retention and its memory cost.

Another name for an existing object, leading to the same inode number: there is no original and no copy. Directories cannot be hard-linked. The number of names that an object carries is its link count (nlink). Also used on: Names: link, unlink, rename, and exchange.

Operation limits​

The opslimit= and opsperuidlimit= export options. They cap how many I/O operations per second a mount using that export may perform, in total and per uid respectively. opslimit makes no exception for root, but opsperuidlimit leaves uid 0 unlimited.

POSIX compliance​

Through a mount, MooseFS behaves like a regular POSIX file system: attributes, hard and symbolic links, special files, ACLs, and locks, coordinated cluster-wide by the Master Server. The features that MooseFS adds on top of POSIX have their own entries here. See POSIX compliance.

Quota​

A limit on how much of the file system one directory subtree may consume, counted in inodes or in one of the three space figures, length, size and realsize. A quota is always set on a directory. See Quota. Also used on: Quota enforcement, The life of a file.

Snapshot​

A copy of a file or of a directory tree created without duplicating chunk data. The snapshot relies on copy-on-write. See Snapshot. Also used on: Snapshot copy-on-write semantics, The life of a file.

Storage class groups (sclassgroups)​

An export option defining which groups of Storage Classes the clients of that export are allowed to set. Also used on: Class priority and export groups.

Sustained files​

Files that a client still holds open after they were deleted, and that the trash does not hold: either their trash retention was zero, or their trash entry was removed while they were open. The Master Server keeps them in the sustained area of the mfsmeta mount until no session holds them open anymore. A deleted file with a trash retention above zero goes to the trash instead, open or not. See Trash and sustained files. Also used on: Trash retention and its memory cost.

Trash retention​

The time that deleted files remain recoverable in the trash, set with mfssettrashretention and constrained per export by mintrashretention and maxtrashretention. Formerly called trashtime. See Trash and sustained files. Also used on: How policies are applied, The life of a file, Timestamps and what moves them, Trash retention and its memory cost.

Multilocations (PRO)​

Default location​

The location that accepts unmapped modules and holds the deciding vote in a tied leader election. The default location cannot be switched off. See Location.

Empty definition and zero definition​

Two ways that a storage state can treat a location: an empty definition inherits the KEEP definition, but a zero definition (-C 0, -K 0, …) explicitly stores no chunks in that location for that state.

Location​

A named segment of a Multilocations cluster consisting of a set of modules. Every module belongs to exactly one location, determined by IP mapping. A location that is to hold data needs at least one Chunkserver of its own. See Location. Also used on: Topology mapping and distance.

Location states (ON, IO, OFF)​

Per-location operating modes: ON (fully operational), IO (available for I/O with replication and rebalance limited), and OFF (disabled). See Location.

Multilocations​

The mechanism for dividing one cluster into logical segments (locations) that correspond to the physical distribution of the cluster's machines, up to 8 locations per cluster. Available from MooseFS 5, PRO only. The literature calls such deployments geo-replication or multi-site. See Multiple locations.

Interfaces and tools​

The command and configuration reference lives in the man pages. The entries below only identify each tool. Several tools ship as a family of commands sharing one man page: such an entry names the family and lists its members.

mfsarchive tools​

Set, clear, and check the archive flag by hand: mfssetarchive, mfsclrarchive, and mfschkarchive.

mfscheckfile​

Reports the state of a file's chunks.

mfschunkdbdump​

Dumps the contents of the chunk database file that a Chunkserver keeps.

mfschunktool​

Checks and repairs chunk files on a Chunkserver disk.

mfsdirinfo​

Shows aggregated information (sizes, counts) for a directory tree.

mfseattr tools​

Read and change extra attributes: mfsgeteattr, mfsseteattr, mfsdeleattr, and mfscopyeattr.

mfsfacl tools​

Read and change POSIX ACLs on MooseFS objects: mfsgetfacl and mfssetfacl.

mfsfileinfo​

Shows where the copies or EC parts of each chunk of a file are stored.

mfsfilepaths​

Lists every path under which a file is visible, and finds the file belonging to a given inode number.

mfsfilerepair​

Attempts to make a damaged file readable again.

mfslicinfo (PRO)​

Displays the properties of the loaded MooseFS PRO license.

mfslocadmin (PRO)​

Creates and manages locations in a Multilocations cluster: mfslocationcreate, mfslocationdelete, mfslocationsetdefault, mfslocationstate, mfslocationmap, mfslocationunmap, mfslocationrename, and mfslocationlist. See Location tasks.

mfsmetadirinfo​

Computes precise directory information from a metadata image: what mfsdirinfo reports, but offline.

mfsmetadump​

Dumps a metadata image in human-readable form.

mfsmetasearch​

Finds files in a metadata image, without a running cluster.

mfsnetdump​

Captures network traffic and decodes it as MooseFS protocol packets.

mfspatadmin​

Creates, lists, and deletes patterns: mfscreatepattern, mfsdeletepattern, and mfslistpattern.

mfspatch (PRO)​

Creates minimal patches to synchronize data between MooseFS instances, for example between snapshots of a backup pair: mfscreatepatch, mfsapplypatch, and mfsdumppatch.

mfsquota tools​

Read, set, remove, and copy quotas: mfsgetquota, mfssetquota, mfsdelquota, and mfscopyquota.

mfsscadmin​

Creates and manages Storage Class definitions: mfscreatesclass, mfsmodifysclass, mfsdeletesclass, mfsclonesclass, mfsrenamesclass, mfslistsclass, and mfsimportsclass.

mfssclass tools​

Read and change the Storage Class assigned to existing objects: mfsgetsclass, mfssetsclass, mfscopysclass, and mfsxchgsclass. The class definitions themselves are managed with mfsscadmin. See Data placement tasks.

mfssnapshots tools​

Create and remove snapshots: mfsmakesnapshot, mfsrmsnapshot, and mfsappendchunks, which appends a lazy copy of one or more files to a target file at chunk boundaries.

mfsstatsdump and mfscsstatsdump​

Dump the chart data that a Master Server or a Chunkserver has recorded in its stats file, as CSV or PNG.

mfssupervisor​

Inspects and controls Master Server states, including forcing a metadata save before upgrades.

mfstrashretention tools​

Read and change trash retention on files and directories: mfsgettrashretention, mfssettrashretention, and mfscopytrashretention. The mfsgettrashtime, mfssettrashtime, and mfscopytrashtime commands are the older names for the same operations: each prints a deprecation line and then carries the operation out.

MooseFS CLI (mfscli)​

The terminal tool for querying cluster status. -S selects the data set, -j produces JSON, and -p plain text. mfscli prints a table otherwise and also feeds the Prometheus exporter.

Prometheus exporter​

The /metrics endpoint of the GUI server exposing cluster metrics with the mfs_ prefix. See Prometheus metrics.

Web GUI​

The web-based monitoring interface served by mfsgui, on port 9425 unless GUISERV_LISTEN_PORT in mfsgui.cfg says otherwise. Older documentation calls this interface the CGI Monitor. See GUI.

Editions and licensing​

Community Edition (CE)​

The open-source edition of MooseFS, licensed under GPLv2, with manual Master Server failover. See Editions: Community and PRO and CE and PRO: feature matrix.

License file (mfslicence.bin)​

The file that carries the terms of a PRO license to the Master Servers, installed as /etc/mfs/mfslicence.bin and pointed to by LICENCE_FILENAME in mfsmaster.cfg. mfslicinfo prints what the license file holds. See License installation.

MooseFS PRO​

The commercial edition with features for enterprise environments, including automatic High Availability, the Windows Client, Multilocations, and Erasure Coding above one parity part. MooseFS PRO runs under a PRO license. See Editions: Community and PRO.

PRO license​

The commercial entitlement that a MooseFS PRO instance runs under: bought perpetually rather than rented, non-transferable, and capped at an agreed amount of used raw space. Community Edition needs no license. See How licensing works.

PRO Personal and PRO Enterprise​

The two PRO license tiers. Both run the same MooseFS PRO packages. The license file tells them apart. Every PRO license caps used raw space at the capacity it was issued for. A Personal license is issued for at most 200 TiB, an Enterprise license for an agreed capacity.