Glossary
========

**Brick**
:   A Brick is the basic unit of storage in GlusterFS, represented by an export
    directory on a server in the trusted storage pool.
    A brick is expressed by combining a server with an export directory in the following format:

        `SERVER:EXPORT`
    For example:
        `myhostname:/exports/myexportdir/`

**Volume**
:   A volume is a logical collection of bricks. Most of the gluster
    management operations happen on the volume.


**Subvolume**
:   A brick after being processed by at least one translator or in other words
    set of one or more xlator stacked together is called a sub-volume.


**Volfile**
:   Volume (vol) files are configuration files that determine the behavior of the
    GlusterFs trusted storage pool. Volume file is a textual representation of a
    collection of modules (also known as translators) that together implement the
    various functions required. The collection of modules are arranged in a graph-like
    fashion. E.g, A replicated volume's volfile, among other things, would have a
    section describing the replication translator and its tunables.
    This section describes how the volume would replicate data written to it.
    Further, a client process that serves a mount point, would interpret its volfile
    and load the translators described in it. While serving I/O, it would pass the
    request to the collection of modules in the order specified in the volfile.

    At a high level,  GlusterFs has three entities,that is, Server, Client and Management daemon.
    Each of these entities have their own volume files.
    Volume files for servers and clients are generated by the management daemon
    after the volume is created.

    Server and Client Vol files are located in /var/lib/glusterd/vols/VOLNAME directory.
    The management daemon vol file is named as glusterd.vol and is located in /etc/glusterfs/
    directory.

**glusterd**
:   The daemon/service that manages volumes and cluster membership. It is required to
    run on all the servers in the trusted storage pool.

**Cluster**
:   A trusted pool of linked computers working together, resembling a single computing resource.
    In GlusterFs, a cluster is also referred to as a trusted storage pool.

**Client**
:   Any machine that mounts a GlusterFS volume. Any applications that use libgfapi access
    mechanism can also be treated as clients in GlusterFS context.


**Server**
:   The machine (virtual or bare metal) that hosts the bricks in which data is stored.


**Block Storage**
:   Block special files, or block devices, correspond to devices through which the system moves
    data in the form of blocks. These device nodes often represent addressable devices such as
    hard disks, CD-ROM drives, or memory regions. GlusterFS requires a filesystem (like XFS) that
    supports extended attributes.



**Filesystem**
:   A method of storing and organizing computer files and their data.
    Essentially, it organizes these files into a database for the
    storage, organization, manipulation, and retrieval by the computer's
    operating system.

    Source: [Wikipedia][]

**Distributed File System**
:   A file system that allows multiple clients to concurrently access data which is spread across
    servers/bricks in a trusted storage pool. Data sharing among multiple locations is fundamental
    to all distributed file systems.

**Virtual File System (VFS)
    VFS is a kernel software layer which handles all system calls related to the standard Linux file system.
    It provides a common interface to several kinds of file systems.

**POSIX**
:   Portable Operating System Interface (for Unix) is the name of a
    family of related standards specified by the IEEE to define the
    application programming interface (API), along with shell and
    utilities interfaces for software compatible with variants of the
    Unix operating system. Gluster exports a fully POSIX compliant file
    system.

**Extended Attributes**
:   Extended file attributes (abbreviated xattr) is a filesystem feature
    that enables users/programs to associate files/dirs with metadata.


**FUSE**
:   Filesystem in Userspace (FUSE) is a loadable kernel module for
    Unix-like computer operating systems that lets non-privileged users
    create their own filesystems without editing kernel code. This is
    achieved by running filesystem code in user space while the FUSE
    module provides only a "bridge" to the actual kernel interfaces.

    Source: [Wikipedia][1]


**GFID**
:   Each file/directory on a GlusterFS volume has a unique 128-bit number
    associated with it called the GFID. This is analogous to inode in a
    regular filesystem.


**Infiniband**
    InfiniBand is a switched fabric computer network communications link
    used in high-performance computing and enterprise data centers.

**Metadata**
:   Metadata is data providing information about one or more other
    pieces of data.

**Namespace**
:   Namespace is an abstract container or environment created to hold a
    logical grouping of unique identifiers or symbols. Each Gluster
    volume exposes a single namespace as a POSIX mount point that
    contains every file in the cluster.

**Node**
:   A server or computer that hosts one or more bricks.

**Open Source**
:   Open source describes practices in production and development that
    promote access to the end product's source materials. Some consider
    open source a philosophy, others consider it a pragmatic
    methodology.

    Before the term open source became widely adopted, developers and
    producers used a variety of phrases to describe the concept; open
    source gained hold with the rise of the Internet, and the attendant
    need for massive retooling of the computing source code.

    Opening the source code enabled a self-enhancing diversity of
    production models, communication paths, and interactive communities.
    Subsequently, a new, three-word phrase "open source software" was
    born to describe the environment that the new copyright, licensing,
    domain, and consumer issues created.

    Source: [Wikipedia][2]

**Petabyte**
:   A petabyte (derived from the SI prefix peta- ) is a unit of
    information equal to one quadrillion (short scale) bytes, or 1000
    terabytes. The unit symbol for the petabyte is PB. The prefix peta-
    (P) indicates a power of 1000:

    1 PB = 1,000,000,000,000,000 B = 10005 B = 1015 B.

    The term "pebibyte" (PiB), using a binary prefix, is used for the
    corresponding power of 1024.

    Source: [Wikipedia][3]



**Quorum**
:   The configuration of quorum in a trusted storage pool determines the
    number of server failures that the trusted storage pool can sustain.
    If an additional failure occurs, the trusted storage pool becomes
    unavailable.

**Quota**
:   Quota allows you to set limits on usage of disk space by directories or
    by volumes.

**RAID**
:   Redundant Array of Inexpensive Disks (RAID) is a technology that
    provides increased storage reliability through redundancy, combining
    multiple low-cost, less-reliable disk drives components into a
    logical unit where all drives in the array are interdependent.

**RDMA**
:   Remote direct memory access (RDMA) is a direct memory access from the
    memory of one computer into that of another without involving either
    one's operating system. This permits high-throughput, low-latency
    networking, which is especially useful in massively parallel computer
    clusters.

**Rebalance**
:   A process of fixing layout and resdistributing data in a volume when a
    brick is added or removed.

**RRDNS**
:   Round Robin Domain Name Service (RRDNS) is a method to distribute
    load across application servers. RRDNS is implemented by creating
    multiple A records with the same name and different IP addresses in
    the zone file of a DNS server.

**Samba**
:   Samba allows file and print sharing between computers running Windows and
    computers running Linux. It is an implementation of several services and
    protocols including SMB and CIFS.

**Self-Heal**
:   The self-heal daemon that runs in the background, identifies
    inconsistencies in files/dirs in a replicated volume and then resolves
    or heals them. This healing process is usually required when one or more
    bricks of a volume goes down and then comes up later.

**Split-brain**
:   This is a situation where data on two or more bricks in a replicated
    volume start to diverge in terms of content or metadata. In this state,
    one cannot determine programitically which set of data is "right" and
    which is "wrong".

**Translator**
:   Translators (also called xlators) are stackable modules where each
    module has a very specific purpose. Translators are stacked in a
    hierarchical structure called as graph. A translator receives data
    from its parent translator, performs necessary operations and then
    passes the data down to its child translator in hierarchy.

**Trusted Storage Pool**
:   A storage pool is a trusted network of storage servers. When you
    start the first server, the storage pool consists of that server
    alone.

**Scale-Up Storage**
:   Increases the capacity of the storage device in a single dimension.
    For example, adding additional disk capacity to an existing trusted storage pool.

**Scale-Out Storage**
    Scale out systems are designed to scale on both capacity and performance.
    It increases the capability of a storage device in single dimension.
    For example, adding more systems of the same size, or adding servers to a trusted storage pool
    that increases CPU, disk capacity, and throughput for the trusted storage pool.

**Userspace**
:   Applications running in user space don’t directly interact with
    hardware, instead using the kernel to moderate access. Userspace
    applications are generally more portable than applications in kernel
    space. Gluster is a user space application.


**Geo-Replication**
:   Geo-replication provides a continuous, asynchronous, and incremental
    replication service from site to another over Local Area Networks
    (LAN), Wide Area Network (WAN), and across the Internet.

**N-way Replication**
:   Local synchronous data replication which is typically deployed across campus
    or Amazon Web Services Availability Zones.

**Distributed Hash Table Terminology**
**Hashed subvolume**
:   A Distributed Hash Table Translator subvolume to which the file or directory name is hashed to.

**Cached subvolume**
:   A Distributed Hash Table Translator subvolume where the file content is actually present.
    For directories, the concept of cached-subvolume is not relevant. It is loosely used to mean
    subvolumes which are not hashed-subvolume.

**Linkto-file**

:   For a newly created file, the hashed and cached subvolumes are the same.
    When directory entry operations like rename (which can change the name and hence hashed
    subvolume of the file) are performed on the file, instead of moving the entire data in the file
    to a new hashed subvolume, a file is created with the same name on the newly hashed subvolume.
    The purpose of this file is only to act as a pointer to the node where the data is present.
    In the extended attributes of this file, the name of the cached subvolume is stored.
    This file on the newly hashed-subvolume is called a linkto-file.
    The linkto file is relevant only for non-directory entities.

**Directory Layout**
:   The directory layout specifies the hash-ranges of the subdirectories of a directory to which
    subvolumes they correspond to.

**Properties of directory layouts:**
:   The layouts are created at the time of directory creation and are persisted as extended attributes
    of the directory.
    A subvolume is not included in the layout if it remained offline at the time of directory creation
    and no directory entries ( such as files and directories) of that directory are created on
    that subvolume. The subvolume is not part of the layout until the fix-layout is complete
    as part of running the rebalance command. If a subvolume is down during access (after directory creation),
    access to any files that hash to that subvolume fails.

**Fix Layout**
:   A command that is executed during the rebalance process.
    The rebalance process itself comprises of two stages:
    Fixes the layouts of directories to accommodate any subvolumes that are added or removed.
    It also heals the directories, checks whether the layout is non-contiguous, and persists the
    layout in extended attributes, if needed. It also ensures that the directories have the same
    attributes across all the subvolumes.

    Migrates the data from the cached-subvolume to the hashed-subvolume.

  [Wikipedia]: http://en.wikipedia.org/wiki/Filesystem
  [1]: http://en.wikipedia.org/wiki/Filesystem_in_Userspace
  [2]: http://en.wikipedia.org/wiki/Open_source
  [3]: http://en.wikipedia.org/wiki/Petabyte
