Skip to main content

Session and export

The two terms cover the two ends of the same act. An export is a rule that decides whether a client may mount the file system at all. A session is the record that the Master Server keeps for a client that has mounted the file system.

What an export is​

An export is a rule in mfsexports.cfg that defines which client IP addresses may mount which part of the namespace and with what options. The Master Server reads the file and checks every registering client against the rules in that file.

A rule names three things: the addresses that it covers, the directory that the clients at those addresses may mount, and the options that apply to the mount. The directory is the root of the MooseFS namespace or a path below it, so different clients can be admitted to different parts of the same file system. A separate form of the rule admits a client to the MooseFS Meta mount instead. The options decide what the mount may then do. They set the access mode, the identity that the users of a client are seen under, and the operations that stay blocked for that mount. Syntax and the full option list are described in the mfsexports.cfg(5) manual page.

A client that no rule covers is refused at mount time. The same happens when the address of the client matches but the path that the client asks for does not. The client is also refused when the rule requires a password that the client did not send.

What a session is​

A session is the Master Server's record of a mounted client. The session is created when a client registers and the export check accepts that client. The client receives a numeric identifier for that session. The session holds the rights taken from the export rule that admitted the client, the address that the client registered from, the files that the client has open, and the operation counters. Every later request from that mount is answered under this record. The decisions of an export therefore take effect in the session, not in the mount command.

A session outlives the connection that created it. A client that loses its connection without unmounting keeps its record for the time set by SESSION_SUSTAIN_TIME in mfsmaster.cfg. The mfsmaster.cfg(5) manual page documents that option. The client returns with the same identifier and the same files still open. Unmounting closes the session instead. The Master Server drops the session without waiting for that time to pass. On reconnection, the Master Server checks the address that the session was created from, unless the export rule allows the client to reconnect from a different address.

Why they matter​

Exports grant or refuse access to the cluster. Every mount goes through the check. The rule that matches sets what the client sees, that is, the subtree that the client is given as its root. The rule also sets what the client is permitted to do inside that subtree. Changing a rule is therefore an access decision, not a client-side setting.

Sessions hold the state of a mounted client. Because a session survives a break in the connection, a client does not lose its open files in a network outage. Because a session holds the rights that the client was admitted with, a mount keeps working under those rights until it registers again. The mounts that the monitoring interfaces list are sessions.

How MooseFS implements it​

The Master Server reads mfsexports.cfg at startup and on reload. The Master Server checks a registering client against the rules and passes the values of the matching rule to the session of the client. When a reload finds that the file has changed, the mounts that registered under its previous contents are disconnected. Those mounts then register again under the current rules.

Sessions are part of the metadata that the Master Server stores, so they survive a restart of the Master Server.