Skip to main content

Client and mount

MooseFS is reached through a client. A client reaches MooseFS through a mount.

What it is​

A client is a machine that reaches a MooseFS instance, most often by mounting the file system. A mount is one attachment of the MooseFS namespace, or of a chosen subtree of it, to a directory on that machine.

Mounting is the usual way to reach a MooseFS instance, but not the only one. MooseFS Block Device (mfsbdev) presents one stored file to the machine as a block device instead of attaching a namespace. libmfsio lets a program reach the instance with no mount point at all. Both are described under the forms of the client below.

Once a mount exists, the directory behaves like any other file system. Applications open, read, write, and rename files in that directory with ordinary POSIX calls. The applications do not have to know that the data is distributed. A machine can have more than one mount at a time. Each mount is attached separately and registers with the cluster separately.

Why it matters​

Client code is the layer between an application and the cluster. An application either works through a mount that a client provides, or links libmfsio and becomes the client itself. Either way, the application reaches the Master Server and the Chunkservers through that code and does not address them directly. The form that you choose decides how the cluster appears to an operating system and to the software that runs on that system. The cluster appears as a file system, as a block device, or as a set of calls inside the program.

Access is decided at the mount, and the Master Server decides it. A mount connects to the Master Server and asks for a directory. The Master Server matches that request against the export rules: the address that the connection comes from, the directory asked for, and the password, if the rule requires one. The mount gets the part of the namespace and the rights that the matching rule grants. The Master Server answers every later request from that mount under those rights, so the client cannot widen them. Session and export covers the rules.

How MooseFS implements it​

The client holds one connection to the Master Server. The client uses that connection for metadata only. The metadata covers name lookups, attributes, and the question of which chunk covers a given part of a file and which Chunkservers hold that chunk. File contents never pass through the Master Server. The client connects to the Chunkservers named in that answer and exchanges the data with them directly.

A client comes in more than one form. The forms differ in how the cluster is presented to the machine, not in what the cluster does:

  • mfsmount mounts the file system through FUSE (Filesystem in Userspace). This form produces a mount point and POSIX file system access. The same program also attaches the MooseFS Meta file system. That file system has no file data and is where deleted files are recovered.
  • MooseFS Block Device (mfsbdev) exposes a single file stored in MooseFS as a block device, so software that expects a raw disk or partition can use that device. MooseFS Block Device runs on Linux only, requires the nbd kernel module, and is itself built on libmfsio.
  • libmfsio is a library that gives a program POSIX-like calls against MooseFS (mfs_open, mfs_read, mfs_write, and the rest) without mounting anything. There is no mount point and no FUSE layer. The program itself becomes the client.
  • Windows Client PRO (PRO Edition only) is a native file system driver for Microsoft Windows. Windows Client communicates with the cluster over the MooseFS protocol.