Skip to main content

Clients

The Client is the module through which applications reach a MooseFS instance. Client and mount covers what a client is and what a mount is. This page describes the forms that the module takes as components of the system: what each form is made of, where it runs, and what limits it. The forms are mfsmount, libmfsio, MooseFS Block Device, and the Windows Client.

Every form holds one connection to the Master Server​

A machine is a client because of its connection to the Master Server, not because of a mount point. Every form registers there, holds a session, and sends its metadata operations over that connection. File data does not pass through that connection: the client exchanges data directly with the Chunkservers, along the read path and the write path.

In the PRO Edition PRO (PRO Edition only) the client finds the Leader Master Server on its own: given the addresses of several Master Servers, the client resolves them all. When the Master Server that the client reaches is not the Leader, the client is redirected to the Leader or retries another address. Leader election and quorum covers how the Leader is chosen.

The forms differ in the layer above the connection: a kernel mount, a library inside the program, a block device, or a Windows file system driver.

mfsmount attaches the file system through FUSE​

mfsmount is the mount form: it attaches the namespace, or a subtree of it, to a directory through FUSE (Filesystem in Userspace). This form gives the machine a POSIX file system and is the usual way to reach a MooseFS instance.

One mfsmount process serves one mount. A machine with several mounts runs several processes, each with a FUSE connection and a session of its own. Multiple mounts covers what mounts share and what they do not. The FUSE layer adds a cost to every operation. That cost is described in what the FUSE layer costs. The single FUSE connection limits how much data one mount moves. That limit is described in the per-mount throughput ceiling.

A mount does more than move data: the process keeps caches of names, attributes, and file data, and runs worker threads that maintain them. Client cache and read-ahead covers what the process caches and for how long. Client background work covers what its threads do between operations.

The same program attaches the MooseFS Meta file system (mfsmount -o mfsmeta), a companion mount that holds no file data and is where deleted files are recovered.

libmfsio makes the program itself the client​

libmfsio is a library. A program that links it reaches the instance through POSIX-like calls with an mfs_ prefix, such as mfs_open, mfs_read, and mfs_write, all declared in the mfsio.h header. The program becomes the client itself: there is no separate client process, no mount point, and no FUSE layer between it and the cluster.

Because there is no FUSE connection, the per-mount throughput ceiling does not apply. The library is the form for an application that needs more from one machine than a single mount carries.

MooseFS Block Device serves one stored file​

MooseFS Block Device (mfsbdev) presents a single file stored in MooseFS to the client machine as a block device. MooseFS Block Device runs on Linux only: the kernel's nbd (Network Block Device) module passes block reads and writes to the mfsbdev daemon. The daemon turns them into I/O on the mapped file.

Structurally the daemon is a program built on libmfsio, so its traffic does not pass through FUSE either. One daemon serves many mappings, which are created and removed with the mfsbdev commands. The mfsbdev(8) manual page, listed in command line tools, covers the tool and its options.

The Windows Client is a separate application​

The Windows Client PRO (PRO Edition only) is a native MooseFS file system driver for Microsoft Windows. The Windows Client ships as an application of its own and uses the same MooseFS protocol as the other forms. Unlike the other client forms, the Windows Client requires a license file that the Master Server holds. The license comes with MooseFS PRO. A Community Edition Master Server can hold the file as well, so the client works with clusters of either edition.

Windows and MooseFS name users differently, so the client maps identities on every operation. The client maps the SID of the Windows user to a uid and gid, which are either set in the client's configuration or resolved through LDAP. The mapping runs in reverse when permissions are shown. The client offers as much POSIX semantics as Windows allows and shares data with the POSIX forms. The limits follow from the differences between the operating systems. POSIX compliance covers where that boundary is.