Metadata and namespace
MooseFS keeps what a file is apart from what a file contains. Metadata is the first of the two.
What it is
Metadata is everything that MooseFS records about a file except the file's content. Metadata covers the name of the file, the directory that holds the file, and the owner, group, permission bits, timestamps, and length of the file. Metadata also covers the attributes that are attached to the file, among them extended attributes and POSIX ACLs. The list of chunks that the file is made of is metadata too. The Master Server holds all of it.
The namespace is the part of that metadata that you recognize as the file system: the tree of directories and the names inside them. Every object in the namespace is an inode: a regular file, a directory, a symbolic link, a FIFO, a socket, or a block or character device. Each inode has a number. A client and the Master Server name an object by that number, not by the path. A lookup asks for one name inside a parent inode and answers with the inode of the child.
Why it matters
Metadata and data are handled by different components and are sent over different connections. A client asks the Master Server to look up a name, create a file, or change the attributes of a file. The client then exchanges the content itself with the Chunkservers. File content never passes through the Master Server.
The same split decides where a cluster runs out of room. Data capacity grows with every disk that you add to a Chunkserver. Metadata capacity does not, because the whole structure is held in the Master Server's RAM. The memory of one machine therefore limits metadata capacity (see Master Server memory and Requirements for Master Servers).
How MooseFS implements it
The Master Server keeps the namespace as two kinds of record. A node is the object itself. The node has the attributes of the object: type, permission bits, owner and group, the three timestamps, Storage Class, extra attributes, and trash retention. An edge is one name in one directory. The edge points from a parent node to a child node.
A name therefore belongs to the link, not to the object. A hard link is several edges that lead to the same node, so one file can be visible under more than one path.
A file node also has the ordered list of the chunks that the file is made of. That list tells the client which chunk covers a given position in the file. A separate map records which Chunkservers currently hold that chunk. The Master Server builds that map from the reports that Chunkservers send when the Chunkservers connect. The Master Server does not keep the map in the saved structure.
Extended attributes, POSIX ACLs, quotas, file locks, Storage Class definitions, and open sessions are metadata as well, and are kept beside the nodes and edges. The Master Server writes the whole structure to the local disk of its own machine and reads the structure back at startup.
Attributes need a warning of their own, because a workload can grow them without meaning to. Every extended attribute is stored per object in the Master Server's RAM. Both a single value and the whole list of names on an object may reach a size far larger than the object's other metadata. The limits are listed on the extended and extra attributes page. A workload that sets attributes on every file therefore grows metadata far beyond what the number of files alone suggests. That growth uses the Master Server's memory (see Master Server memory).