mdoc

package: mono-monodoc

title: mdoc(5)

summary: Mono Documentation XML Format

text:
# mdoc(5)

## NAME
mdoc - Mono Documentation XML Format

## DESCRIPTION
The assorted Mono documentation programs generate or manipulate XML files following the mono documentation schema:

mdoc update

Creates or updates mono documentation XML for a set of assemblies.

mdoc validate

Validates the mono documentation XML against the mono documentation XML schema.

mdoc assemble

Converts the mono documentation XML within a directory structure into a set of files for use with monodoc(1).

mdoc export-html

Converts the mono documentation XML within a directory structure into a set of HTML files that can be viewed with a web browser.

All of these tools (and more) use the common XML schema described in this man page.

## FILE/DIRECTORY STRUCTURE
There are three sets of Mono documentation XML files:

*

index.xml: contains a list of all assemblies within the containing directory, and all types and namespaces within those assemblies.

*

ns-*.xml: There is one ns-*.xml file for each namespace within the assembly; these files are siblings to index.xml . Examples of ns-*.xml files include: ns-System.xml, ns-System.Collections.xml, and ns-.xml (for the root namespace, though it is recommended to NOT place types into the root namespace, as monodoc(1) doesn't display them).

The ns-*.xml files contain per-namespace documentation.

*

NamespaceName/TypeName.xml: These files are within a dotted NamespaceName directory, and TypeName is the name of the type. Examples include: RootType.xml (if the type has no namespace), System/String.xml, System.Collections/IEnumerable.xml, and System.Collections.Generic/List`1+Enumerator.xml (the `1 is the number of generic type parameters the type accepts, and everything after the + is a nested type).

Thus, typical directory contents would resemble:

```
    index.xml

    ns-System.xml

    ns-System.Collections.Generic.xml

    System/String.xml

    System.Collections.Generic/List`1.xml
```

## DOCUMENTATION FORMAT

### index.xml File Format
The index.xml file contains a list of the assemblies nested under the directory containing index.xml and all namespaces and types within those assemblies. It looks something like this:

```
    <Overview>

      <Assemblies>

        <Assembly Name="mscorlib" Version="2.0.0.0" />

        <!-- other <Assembly/> elements... -->

      </Assemblies>

      <Remarks>To be added.</Remarks>

      <Copyright>To be added.</Copyright>

      <Types>

        <Namespace Name="System">

          <Type Name="String" />

          <!-- Other <Type/> elements -->

        </Namespace>

        <Namespace Name="System.Collections.Generic">

          <Type Name="List`1" DisplayName="List<T>" />

          <!-- Other <Type/> elements -->

        </Namespace>

        <!-- other <Namespace/> elements -->

      </Types>

      <Title>DocTest</Title>

    </Overview>
```

Most of this is maintained automatically, in particular the /Overview/Assemblies and /Overview/Types elements.

The //Namespace/@Name attribute corresponds to a directory which contains files named //Type/@Name.xml, while the //Type/@DisplayName attribute contains a C# type name (if //Type/@DisplayName isn't found, then //Type/@Name is used as the display name). There should also be a ns-[//Namespace/@Name].xml file.

There are three elements of interest to authors: /Overview/Remarks, /Overview/Copyright, and /Overview/Title, which contain assembly-level documentation. These elements can contain any of the following XML elements (documented in the Documentation XML Elements section): block, code, example, list, para, paramref, typeparamref, see, and ul.

### ns-*.xml File Format
The ns-*.xml files contain namespace documentation:

```
    <Namespace Name="System">

      <Docs>

        <summary>To be added.</summary>

        <remarks>To be added.</remarks>

      </Docs>

    </Namespace>
```

The /Namespace/Docs/summary and /Namespace/Docs/remarks elements should contain namespace documentation.

The remarks and summary elements are documented in the Documentation XML Elements section.

### NamespaceName/TypeName.xml File Format
The mono documentation format is similar to the Ecma documentation format, as described in ECMA-335 3rd Edition, Partition IV, Chapter 7. The principal difference from the ECMA format is that each type gets its own file, within a directory identical to the namespace of the type. There is a lot of information that is maintained automatically by mdoc(1); Most of the information within the documentation should not be edited. This includes the type name (/Type/@FullName), implemented interfaces (/Type/Interfaces), member information (/Type/Members/Member/@MemberName, /Type/Members/Member/MemberSignature, /Type/Members/Member/MemberType, /Type/Members/Member/Parameters, etc.).

```
    <Type Name="DocAttribute" FullName="Mono.DocTest.DocAttribute">

      <TypeSignature Language="C#" Value="public class DocAttribute : Attribute" />

      <AssemblyInfo>

        <AssemblyName>DocTest</AssemblyName>

        <AssemblyVersion>0.0.0.0</AssemblyVersion>

      </AssemblyInfo>

      <Base>

        <BaseTypeName>System.Attribute</BaseTypeName>

      </Base>

      <Interfaces />

      <Attributes>

        <Attribute>

          <AttributeName>System.AttributeUsage(System.AttributeTargets.All)</AttributeName>

        </Attribute>

      </Attributes>

      <Docs>

        <summary>To be added.</summary>

        <remarks>To be added.</remarks>

      </Docs>

      <Members>

        <Member MemberName=".ctor">

          <MemberSignature Language="C#" Value="public DocAttribute (string docs);" />

          <MemberType>Constructor</MemberType>

          <AssemblyInfo>

            <AssemblyVersion>0.0.0.0</AssemblyVersion>

          </AssemblyInfo>

          <Parameters>

            <Parameter Name="docs" Type="System.String" />

          </Parameters>

          <Docs>

            <param name="docs">To be added.</param>

            <summary>To be added.</summary>

            <remarks>To be added.</remarks>

          </Docs>

        </Member>

      </Members>

    </Type>
```

The only elements that normally need to be edited are children of the //Docs elements, which usually contain the text To be added. The /Type/Docs element contains type-level documentation, while the /Type/Members/Member/Docs element contains per-member documentation.

The //Docs elements can contain the following elements: altcompliant, altmember, example, exception, param, permission, remarks, returns, since, summary, threadsafe, typeparam, and value.

Nested types are not members; they are types, and are documented in their own file. Consequently, the NamespaceName/TypeName.xml files are not recursive; you do not store a <Type/> element within a <Type/> element.

### Documentation XML Elements
The contents of the Docs element is identical in semantics and structure to the inline C# documentation format, consisting of these elements (listed in ECMA-334 3rd Edition, Annex E, Section 2). The following are used within the element descriptions:

CREF

Refers to a class (or member) reference, and is a string in the format described below in the CREF FORMAT section.

TEXT

Non-XML text, and XML should not be nested.

XML

Only XML elements should be nested (which indirectly may contain text), but non-whitespace text should not be an immediate child node.

XML_TEXT

Free-form text and XML, so that other XML elements may be nested.

The following elements are used in documentation:

<altmember cref="CREF" />

<altmember/> is a top-level element, and should be nested directly under the <Docs/> element. Allows an entry to be generated for the See Also section. Use <see/> to specify a link from within text.

```
    <altmember cref="P:System.Exception.Message" />
```

<block subset="SUBSET" type="TYPE">XML_TEXT</block>

Create a block of text, similar in concept to a paragraph, but is used to create divisions within the text. To some extent, a <block/> is equivalent to the HTML
 tag. SUBSET should always be the value "none".

TYPE specifies the heading and formatting to use. Recognized types are:

behaviors Creates a section with the heading Operation.

note Creates a section with the heading Note:.

overrides Creates a section with the heading Note to Inheritors.

usage Creates a section with the heading Usage.

The block element can contain the following elements: block, c, code, list, para, paramref, see, subscript, sup, and typeparamref.

<c>XML_TEXT</c>

Set text in a code-like font (similar to the HTML <tt/> element). The c element can contain the following elements: code, para, paramref, see, and typeparamref.

TEXT

Display multiple lines of text in a code-like font (similar to the HTML
 element). LANGUAGE is the language this code block is for. For example, if LANGUAGE is C#, then TEXT will get syntax highlighting for the C# language within the Mono Documentation Browser.

SOURCE is only interpreted by mdoc-update(1). If the src attribute is present when mdoc-update(1) is run, then SOURCE is a file (relative to mdoc-update(1)'s --out directory) that should be inserted as the value for TEXT. The contents of TEXT will be ignored by mdoc-update(1) and replaced on every invocation. SOURCE can also contain an "anchor", e.g. src="path/to/file.cs#RegionMarker". If an anchor is present, and LANGUAGE is C#, then #region RegionMarker will be searched for, and the contents between the #region and the following #endregion will be inserted as the value for TEXT element.

<example>XML_TEXT</example>

Indicates an example that should be displayed specially. For example:

```
    <example>

      <para>An introductory paragraph.</para>

      <code lang="C#">

        class Example {

          public static void Main ()

          {

            System.Console.WriteLine ("Hello, World!");

          }

        }

      </code>

    </example>
```

The example element can contain the following elements: c, code, list, para, and see.

<exception cref="CREF">XML_TEXT</exception>

Identifies an exception that can be thrown by the documented member. <exception/> is a top-level element, and should be nested directly under the <Docs/> element.

CREF is the exception type that is thrown, while XML_TEXT contains the circumstances that would cause CREF to be thrown.

```
    <exception cref="T:System.ArgumentNullException">

      <paramref name="foo" /> was <see langword="null" />.

    </exception>
```

The exception element can contain the following elements: block, para, paramref, see, and typeparamref.

<format type="TYPE">XML_TEXT</format>

The <format/> element is an "escape hatch," for including (possibly XML) content that is not valid mdoc(5) content. It's the moral equivalent of perlpod(1) =begin format blocks. TYPE is the mime type of XML_TEXT. mdoc(5) processors may skip format/> blocks of they use a type that isn't supported.

For example:

```
    <format type="text/html">

      <table width="100%">

        <tr><td style="color:red">Hello, world!</td></tr>

      </table>

    </format>
```

would cause the embedded HTML
 element to be inserted inline into the resulting HTML document when mdoc-export-html(1) processes the file. (Likewise, it may be skipped if processed by another program.)

format/> is intended to simplify importing documentation from existing documentation sources. It should not be relied upon, if at all possible.

<list>XML</list>

Create a list or table of items. <list/> makes use of nested <item>XML</item>, <listheader>XML</listheader>, <term>XML_TEXT</term>, and <description>XML_TEXT</description> elements. Lists have the syntax:

```
    <list type="bullet"> <!-- or type="number" -->

      <item><term>Bullet 1</term></item>

      <item><term>Bullet 2</term></item>

      <item><term>Bullet 3</term></item>

    </list>
```

Tables have the syntax:

```
    <list type="table">

      <listheader> <!-- listheader bolds this row -->

        <term>Column 1</term>

        <description>Column 2</description>

        <description>Column 3</description>

      </listheader>

      <item>

        <term>Item 1-A</term>

        <description>Item 1-B</description>

        <description>Item 1-C</description>

      </item>

      <item>

        <term>Item 2-A</term>

        <description>Item 2-B</description>

        <description>Item 2-C</description>

      </item>

    </list>
```

The item and description elements can each contain text and the following elements: block, c, para, paramref, see, sup, and typeparamref.

<para>XML_TEXT</para>

Insert a paragraph of XML_TEXT. For example,

```
    <para>

      This is a paragraph of text.

    </para>
```

The para element can contain the following elements: block, c, example, link, list, onequarter, paramref, see, sub, sup, typeparamref, and ul.

<param name="NAME">XML_TEXT</param>

<param/> is a top-level element, and should be nested directly under the <Docs/> element. Describes the parameter NAME of the current constructor, method, or property:

```
    <param name="count">

      A <see cref="T:System.Int32" /> containing the number

      of widgets to process.

    </param>
```

The param element can contain the following elements: block, c, example, para, paramref, see, and typeparamref.

<paramref name="NAME" />

Indicates that NAME is a parameter. This usually renders NAME as italic text, so it is frequently (ab)used as an equivalent to the HTML  element. See the <exception/> documentation (above) for an example.

<permission cref="CREF">XML_TEXT</permission>

Documents the security accessibility requirements of the current member. <permission/> is a top-level element, and should be nested directly under the <Docs/> element.

CREF is a type reference to the security permission required, while XML_TEXT is a description of why the permission is required.

```
    <permission cref="T:System.Security.Permissions.FileIOPermission">

      Requires permission for reading and writing files. See

      <see cref="F:System.Security.Permissions.FileIOPermissionAccess.Read" />,

      <see cref="F:System.Security.Permissions.FileIOPermissionAccess.Write" />.

    </permission>
```

The permission element can contain the following elements: block, para, paramref, see, and typeparamref.

<remarks>XML_TEXT</remarks>

Contains detailed information about a member. <remarks/> is a top-level element, and should be nested directly under the <Docs/> element.

```
    <remarks>

      Insert detailed information here.

    </remarks>
```

The remarks element can contain the following elements: block, c, code, example, list, para, paramref, see, and typeparamref.

<returns>XML_TEXT</returns>

<returns/> is a top-level element, and should be nested directly under the <Docs/> element.

Describes the return value of a method:

```
    <returns>

      A <see cref="T:System.Boolean" /> specifying whether

      or not the process can access

      <see cref="P:Mono.Unix.UnixFileSystemInfo.FullName" />.

    </returns>
```

The returns element can contain the following elements: c, format, list, para, paramref, see, and typeparamref.

<see cref="CREF" />, <see langword="LANGWORD" />

Creates a link to the specified member within the current text:

```
    <see cref="M:Some.Namespace.With.Type.Method" />
```

or specifies that LANGWORD is a language keyword:

```
    <see langword="null" />
```

<seealso cref="CREF" />

Do not use seealso, use altmember.

<since version="VERSION" />

<since/> is a top-level element, and should be nested directly under the <Docs/> element.

Permits specification of which version introduced the specified type or member.

```
    <since version="Gtk# 2.4" />
```

This generally isn't required, as the //AssemblyInfo/AssemblyVersion elements track which assembly versions contain type or member.

XML_TEXT

 is a top-level element, and should be nested directly under the <Docs/> element.

Provides a (brief!) overview about a type or type member.

This is usually displayed as part of a class declaration, and should be a reasonably short description of the type/member. Use <remarks/> for more detailed information.

The summary element can contain the following elements: block, list, para, paramref, see, and typeparamref.

<typeparam name="NAME">XML_TEXT</typeparam>

<typeparam/> is a top-level element, and should be nested directly under the <Docs/> element. This is used to document a type parameter for a generic type or generic method.

NAME is the name of the type parameter, while XML_TEXT contains a description of the parameter (what it's used for, what restrictions it must meet, etc.).

```
    <typeparam name="T">

      The type of the underlying collection

    </typeparam>
```

The typeparam element can contain the following elements: block, c, para, paramref, see, and typeparamref.

<typeparamref name="NAME">

Used to indicate that NAME is a type parameter.

<value>XML_TEXT</value>

<value/> is a top-level element, and should be nested directly under the <Docs/> element. Allows a property to be described.

```
    <value>

      A <see cref="T:System.String" /> containing a widget name.

    </value>
```

The value element can contain the following elements: block, c, example, list, para, paramref, see, and typeparamref.

## CREF FORMAT
String IDs (CREFs) are used to refer to a type or member of a type. String IDs are documented in ECMA-334 3rd Edition, Annex E.3.1. They consist of a member type prefix, the full type name (namespace + name, separated by .), possibly followed by the member name and other information.

Member type prefixes:

C:

The CREF refers to a constructor. The (optional) parameter list is enclosed in parenthesis and follows the type name: C:System.String(System.Char,System.Int32).

E:

The CREF refers to an event. The event name follows the type name: E:System.AppDomain.AssemblyLoad.

F:

The CREF refers to a field. The field name follows the type name: F:System.Runtime.InteropServices.DllImportAttribute.SetLastError.

M:

Refers to a constructor or method. Constructors may append .ctor to the type name (instead of using the above C: constructor format), while methods append the method name and an (optional) count of the number of generic parameters. Both constructors and methods may append the method parameter list enclosed in parenthesis. Examples: M:System.Object..ctor, M:System.String..ctor(System.Char[]), M:System.String.Concat(System.Object), M:System.Array.Sort``1(``0[]), M:System.Collections.Generic.List`1..ctor, M:System.Collections.Generic.List`1.Add(`0).

N:

Refers to a namespace, e.g. N:System.

P:

Refers to a property. If the property is an indexer or takes parameters, the parameter types are appended to the property name and enclosed with parenthesis: P:System.String.Length, P:System.String.Chars(System.Int32).

T:

The CREF refers to a type, with the number of generic types appended: T:System.String, T:System.Collections.Generic.List`1, T:System.Collections.Generic.List`1.Enumerator.

To make matters more interesting, generic types & members have two representations: the "unbound" representation (shown in examples above), in which class names have the count of generic parameters appended to their name. There is also a "bound" representation, in which the binding of generic parameters is listed within '{' and '}' or '<' and '>'. (Use of '<' and '>' is less common, as within an XML document their escaped character entities must instead be used, leading to '<' and '>'.)

Unbound:

*

T:System.Collections.Generic.List`1

*

T:System.Collections.Generic.Dictionary`2

Bound:

*

T:System.Collections.Generic.List{System.Int32}

*

T:System.Collections.Generic.List<System.Int32>

*

T:System.Collections.Generic.List<System.Int32>

*

T:System.Predicate{System.Action{System.String}}

As you can see, bound variants can be arbitrarily complex (just like generics).

Furthermore, if a generic parameter is bound to the generic parameter of a type or method, the "index" of the type/method's generic parameter is used as the binding, so given

```
    class FooType {

      public static void Foo<T> (System.Predicate<T> predicate)

      {

      }

    }
```

The CREF for this method is M:FooType.Foo``1(System.Predicate{``0}), ``0 is the 0th generic parameter index which is bound to System.Predicate<T>.

## SEE ALSO
mdoc(1), monodocer(1)

## MAILING LISTS
Visit http://lists.ximian.com/mailman/listinfo/mono-docs-list for details.

## WEB SITE
Visit http://www.mono-project.com for details


mfschunkserver.cfg

package: moosefs-chunkserver

title: mfschunkserver.cfg(5)

text:
# mfschunkserver.cfg(5)

## NAME
mfschunkserver.cfg - main configuration file for mfschunkserver

## DESCRIPTION
The file mfschunkserver.cfg contains configuration of MooseFS chunkserver process.

## SYNTAX
Syntax is:

OPTION = VALUE

Lines starting with # character are ignored as comments.

## OPTIONS
Configuration options:

WORKING_USER

user to run daemon as

WORKING_GROUP

group to run daemon as; optional value - if empty then default user group will be used

SYSLOG_IDENT

name of process to place in syslog messages; default is mfschunkserver

LOCK_MEMORY

whether to perform mlockall() to avoid swapping out mfschunkserver process; default is 0, i.e. no

LIMIT_GLIBC_MALLOC_ARENAS

limit malloc arenas to given value - prevents server from using huge amount of virtual memory (Linux onty, default is 4)

DISABLE_OOM_KILLER

disable out of memory killer (Linux only, default is 1)

NICE_LEVEL

nice level to run daemon with; default is -19; note: process must be started as root to increase priority, if setting of priority fails, process retains the nice level it started with

FILE_UMASK

set default umask for group and others (user has always 0); default is 027 - block write for group and block all for others

DATA_PATH

where to store daemon lock file

HDD_CONF_FILENAME

alternate location/name of mfshdd.cfg file

HDD_TEST_FREQ

This option is deprecated. Please define HDD_TEST_SPEED instead. If HDD_TEST_SPEED is not defined then system will try to use HDD_TEST_FREQ but will convert it to HDD_TEST_SPEED using formula: HDD_TEST_SPEED = 10 / HDD_TEST_FREQ

HDD_TEST_SPEED

Speed of background chunk tests in MB/s per disk (formally entry defined in mfshdd.cfg). Value can be given as a decimal number; default is 1.0

HDD_MIN_TEST_INTERVAL

prevents from testing chunk integrity when last I/O (including test) was performed less than HDD_MIN_TEST_INTERVAL seconds ago; default is 86400

HDD_FADVISE_MIN_TIME

If possible use posix_fadvise(POSIX_DONTNEED) after each chunk test (but only if last I/O operation was performed more than HDD_FADVISE_MIN_TIME seconds ago). Using zero will always perform posix_fadvise (flush cache) and using negative value will never flush cache after tests. This setting is valid only for system s that support posix_fadivise; default value is 86400

HDD_LEAVE_SPACE_DEFAULT

how much space should be left unused on each hard drive; number format: [0-9]*(.[0-9]*)?([kMGTPE]|[KMGTPE]i)?B? ; default is 256MiB; examples: 0.5GB, .5G, 2.56GiB, 1256M etc.

HDD_REBALANCE_UTILIZATION

percent of total work time the chunkserver is allowed to spend on hdd space rebalancing; default is 20

HDD_HIGH_SPEED_REBALANCE_LIMIT

maximum simultaneous writes in high speed disk rebalance (0 means use standard rebalance; default is 0)

HDD_ERROR_TOLERANCE_COUNT, HDD_ERROR_TOLERANCE_PERIOD

how many i/o errors (COUNT) to tolerate in given amount of seconds (PERIOD) on a single hard drive; if the number of errors exceeds this setting, the offending hard drive will be marked as damaged; defaults are 2 and 600

HDD_FSYNC_BEFORE_CLOSE

enables/disables fsync before chunk closing; default is 0 (off)

HDD_SPARSIFY_ON_WRITE

enables/disables sparsification (skip leading and trailing zeroz) during writing new block; default is 1 (on)

HDD_RR_CHUNK_COUNT

how many chunks should be created in one directory before moving to the next one; higher values are better with most OSes cacheing algorithms, low values lead to more even chunk distribution; default is 10000 which works best in most cases

HDD_KEEP_DUPLICATES_HOURS

how many hours duplicate chunks should be kept before deleting (default is 168 - one week); changign this value and reloading will reset the counter

ALLOW_STARTING_WITH_INVALID_DISKS

when set to one chunkserver will not abort start even when incorrect entries are found in 'mfshdd.cfg' file; default is 0 (do not start with invalid entries)

WORKERS_MAX, WORKERS_MAX_IDLE

maximum number of active workers and maximum number of idle workers; defaults are 250 and 40

LABELS

labels string defined as a set of letters (case insensitive) separated by colon or semicolon; default is empty - no labels

BIND_HOST

local address to use for master connections; default is *, i.e. default local address

MASTER_HOST

MooseFS master host, IP is allowed only in single-master installations; default is mfsmaster

MASTER_PORT

MooseFS master command port; default is 9420

MASTER_CONTROL_PORT

MooseFS master control port; default is 9419

MASTER_TIMEOUT

timeout in seconds for master connections (if not 0); If this value is zero then chunkserver sets it initially to 10 and asks master for this value. default is 0 (ask master).

MASTER_RECONNECTION_DELAY

delay in seconds before trying to reconnect to master after disconnection (default is 5)

AUTH_CODE

authentication string (used only when master requires authorization)

BIND_HOST

local address to use for connecting with master (default is *, i.e. default local address)

CHUNKS_PER_REGISTER_PACKET

maximum number of chunks system will try to put in a single register message (default is 10000, limits 1000-100000)

CSSERV_LISTEN_HOST

IP address to listen on for client (mount) connections (* means any)

CSSERV_LISTEN_PORT

port to listen on for client (mount) connections (default is 9422)

## COPYRIGHT
Copyright (C) 2020 Jakub Kruszona-Zawadzki, Core Technology Sp. z o.o.

This file is part of MooseFS.

MooseFS is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2 (only).

MooseFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with MooseFS; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02111-1301, USA or visit http://www.gnu.org/licenses/gpl-2.0.html

## SEE ALSO
mfschunkserver(8), mfshdd.cfg(5)


mfshdd.cfg

title: mfshdd.cfg(5)

text:
# mfshdd.cfg(5)

## NAME
mfshdd.cfg - list of MooseFS storage directories for mfschunkserver

## DESCRIPTION
The file mfshdd.cfg contains list of directories (mountpoints) used for MooseFS storage.

## SYNTAX
Syntax is:

[*|<|>|~]PATH [SPACE LIMIT]

Lines starting with # character are ignored as comments.

Path can be prefixed with one or more special characters. These characters work as additional options.

*

means this directory (hard drive) is "marked for removal" and all data will be replicated to other hard drives, usually on other chunkservers

<

means that all data from this hard drive should be moved to other local hard drives

>

means that all data from other local hard drives should be moved to this hard drive

~

means that significant (more than 10% in less than minute) change of total blocks count will not mark this drive as damaged (useful for compressed filesystems)

PATH is path to the mounting point of storage directory, usually a single hard drive.

SPACE LIMIT is optional space limit, that allows to set one of two values: how much space should be left unused on this device or how much space is to be used on this device. Definition format: [0-9]*(.[0-9]*)?([kMGTPE]|[KMGTPE]i)?B?, positive value means how much space to use, negative value means how much space should be left unused.

## COPYRIGHT
Copyright (C) 2020 Jakub Kruszona-Zawadzki, Core Technology Sp. z o.o.

This file is part of MooseFS.

MooseFS is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2 (only).

MooseFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with MooseFS; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02111-1301, USA or visit http://www.gnu.org/licenses/gpl-2.0.html

## SEE ALSO
mfschunkserver(8), mfschunkserver.cfg(5)


mfsexports.cfg

package: moosefs-master

title: mfsexports.cfg(5)

summary: MooseFS access control for mfsmounts

text:
# mfsexports.cfg(5)

## NAME
mfsexports.cfg - MooseFS access control for mfsmounts

## DESCRIPTION
The file mfsexports.cfg contains MooseFS access list for mfsmount clients.

## SYNTAX
Syntax is:

ADDRESS DIRECTORY [OPTIONS]

Lines starting with # character are ignored as comments.

ADDRESS can be specified in several forms:

```
*	all addresses
n.n.n.n	single IP address
n.n.n.n/b	IP class specified by network address and number of significant bits
n.n.n.n/m.m.m.m	IP class specified by network address and mask
f.f.f.f-t.t.t.t	IP range specified by from-to addresses (inclusive)
```

DIRECTORY can be / or path relative to MooseFS root; special value . means MFSMETA companion filesystem.

OPTIONS list:

ro, readonly

export tree in read-only mode; this is default

rw, readwrite

export tree in read-write mode

alldirs

allows to mount any subdirectory of specified directory (similarly to NFS)

dynamicip

allows reconnecting of already authenticated client from any IP address (the default is to check IP address on reconnect)

ignoregid

disable testing of group access at mfsmaster level (it's still done at mfsmount level) - in this case "group" and "other" permissions are logically added; needed for supplementary groups to work (mfsmaster receives only user primary group information)

admin

administrative privileges - currently: allow changing of quota values and storage classes management

maproot=USER[:GROUP]

maps root (uid=0) accesses to given user and group (similarly to maproot option in NFS mounts); USER and GROUP can be given either as name or number; if no group is specified, USER's primary group is used. Names are resolved on mfsmaster side (see note below).

mapall=USER[:GROUP]

like above but maps all non privileged users (uid!=0) accesses to given user and group (see notes below).

password=PASS, md5pass=MD5

requires password authentication in order to access specified resource

minversion=VER

rejects access from clients older than specified

mingoal=N, maxgoal=N

specify range in which goal can be set by users

mintrashtime=TDUR, maxtrashtime=TDUR

specify range in which trashtime can be set by users

disable=OPERATION[:OPERATION[:...]]

do not allow the client to perform certain operations

Default options are: ro, maproot=999:999, mingoal=1, maxgoal=9, mintrashtime=0, maxtrashtime=4294967295.

## NOTES
USER and GROUP names (if not specified by explicit uid/gid number) are resolved on mfsmaster host.

TDUR can be specified as number without time unit (number of seconds) or combination of numbers with time units. Time units are: W,D,H,M,S. Order is important - less significant time units can't be defined before more significant time units. Time units are case insensitive.

Option mapall works in MooseFS in different way than in NFS, because MooseFS is using FUSE's "default_permissions" option. When mapall option is used, users see all objects with uid equal to mapped uid as their own and all other as root's objects. Similarly objects with gid equal to mapped gid are seen as objects with current user's primary group and all other objects as objects with group 0 (usually wheel). With mapall option set attribute cache in kernel is always turned off.

Option disable can take many parameters (operations to disable) in two ways: as a list separated by colons (:) or by repeating the option many times. List of operations that can be disabled:

```
chown        - don't allow the client to perform the chown operation
chmod        - don't allow the client to perform the chmod operation
symlink      - don't allow the client to create symbolic links
mkfifo       - don't allow the client to create FIFOs
mkdev        - don't allow the client to create devices
mksock       - don't allow the client to create sockets
mkdir        - don't allow the client to create directories
unlink       - don't allow the client to remove non directory objects (will also deny move/rename operation if target inode already exists!)
rmdir        - don't allow the client to remove directories (will also deny move/rename operation if target inode already exists!)
rename       - don't allow the client to change inodes (files, directories) names
move         - don't allow the client to move inodes (files, directories) to another path
link         - don't allow the client to create hard links
create       - don't allow the client to create new files
readdir      - don't allow the client to list directories ('ls' command will not work)
read         - don't allow the client to read from files
write        - don't allow the client to write to files
truncate     - don't allow the client to shorten the length of a file with truncate command
setlength    - don't allow the client to increase the length of a file with truncate command
appendchunks - don't allow the client to add chunks from one file to another (mfsappendchunks)
snapshot     - don't allow the client to create snapshots
settrash     - don't allow the client to change trash retention time
setsclass    - don't allow the client to set storage classes
seteattr     - don't allow the client to set mfs extra attributes
setxattr     - don't allow the client to set XATTRs
setfacl      - don't allow the client to set ACLs
```

## EXAMPLES

```
*                    /       ro
192.168.1.0/24       /       rw
192.168.1.0/24       /       rw,alldirs,maproot=0,password=passcode
10.0.0.0-10.0.0.5    /test   rw,maproot=nobody,password=test
10.1.0.0/255.255.0.0 /public rw,mapall=1000:1000
10.2.0.0/16          /       rw,alldirs,maproot=0,mintrashtime=2h30m,maxtrashtime=2w
192.168.1.0/24       /       rw,disable=unlink:rmdir:truncate
192.168.1.0/24       /       rw,disable=unlink,disable=rmdir,disable=truncate
```

## REPORTING BUGS
Report bugs to <bugs@moosefs.com>.

## COPYRIGHT
Copyright (C) 2020 Jakub Kruszona-Zawadzki, Core Technology Sp. z o.o.

This file is part of MooseFS.

MooseFS is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2 (only).

MooseFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with MooseFS; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02111-1301, USA or visit http://www.gnu.org/licenses/gpl-2.0.html

## SEE ALSO
mfsmaster(8), mfsmaster.cfg(5)


mfsmaster.cfg

title: mfsmaster.cfg(5)

summary: main configuration file for mfsmaster

text:
# mfsmaster.cfg(5)

## NAME
mfsmaster.cfg - main configuration file for mfsmaster

## DESCRIPTION
The file mfsmaster.cfg contains configuration of MooseFS master process.

## SYNTAX
Syntax is:

OPTION = VALUE

Lines starting with # character are ignored as comments.

## OPTIONS
Configuration options:

WORKING_USER

user to run daemon as

WORKING_GROUP

group to run daemon as; optional value - if empty then default user group will be used

SYSLOG_IDENT

name of process to place in syslog messages; default is mfsmaster

LOCK_MEMORY

whether to perform mlockall() to avoid swapping out mfsmaster process; default is 0, i.e. no

LIMIT_GLIBC_MALLOC_ARENAS

limit malloc arenas to given value - prevents server from using huge amount of virtual memory (Linux onty, default is 4)

DISABLE_OOM_KILLER

disable out of memory killer (Linux only, default is 1)

NICE_LEVEL

nice level to run daemon with; default is -19; note: process must be started as root to increase priority, if setting of priority fails, process retains the nice level it started with

FILE_UMASK

set default umask for group and others (user has always 0); default is 027 - block write for group and block all for others

DATA_PATH

where to store metadata files and lock file

EXPORTS_FILENAME

alternate location/name of mfsexports.cfg file

TOPOLOGY_FILENAME

alternate location/name of mfstopology.cfg file

LICENCE_FILENAME

alternate location/name of mfslicence.bin file (pro version only)

BACK_LOGS

number of metadata change log files (default is 50)

METADATA_SAVE_FREQ

how often (in hours) master will store metadata (default is 1)

METADATA_DOWNLOAD_FREQ

how often (in hours) leader will download metadata from followers (pro version only ; default is 24)

METADATA_DOWNLOAD_LIMIT

metadata downloading limit in mebibytes per second (pro version only ; 0 means no limit, default is 50 - 50MiB/s = ~52.4MB/s)

BACK_META_KEEP_PREVIOUS

number of previous metadata files to be kept (default is 1)

CHANGELOG_PRESERVE_SECONDS

how many seconds of change logs have to be preserved in memory (default is 1800; this sets the minimum, actual number may be a bit bigger due to logs being kept in 5k blocks; zero disables extra logs storage)

CHANGELOG_SAVE_MODE

Changelog save mode (default is 0)

0 - write in background by different process (less safe, but doesn't make master stop in case of heavy hdd load)

1 - write in foreground without syncing data (master waits for every changelog to be saved to hdd, but without syncing - a little more safe than the background option, but may cause master to stop and wait for flushing hdd buffers)

2 - write in foreground with fsync after each write (very safe, but may make your master very slow unless you have very sophisticated hardware)

MISSING_LOG_CAPACITY

how many missing chunks will be stored in master (up to 100*MISSING_LOG_CAPACITY bytes of memory will be allocated ; default value is 100000)

MATOML_LISTEN_HOST

IP address to listen on for metalogger, masters and supervisors connections (* means any)

MATOML_LISTEN_PORT

port to listen on for metalogger, masters and supervisors connections

MASTER_HOST

MooseFS master host, IP is allowed only in single-master installations (pro version only ; default is mfsmaster)

MASTER_RECONNECTION_DELAY

delay in seconds before next try to reconnect to master-leader if not connected (pro version only ; default is 5)

MASTER_TIMEOUT

timeout in seconds for master-leader connections (pro version only ; default is 10)

BIND_HOST

local address to use for connecting with master-leader (pro version only ; default is *, i.e. default local address)

MATOCS_LISTEN_HOST

IP address to listen on for chunkserver connections (* means any)

MATOCS_LISTEN_PORT

port to listen on for chunkserver connections

MATOCS_TIMEOUT

default timeout in seconds for master-chunkserver connection (default is 10)

AUTH_CODE

Optional authentication string. When defined - then only chunkservers with the same AUTH_CODE are allowed to connect to this master. When not defined (default) - then all chunkservers are allowed. If you want to switch on chunkserver authentication, then first define AUTH_CODE in all your chunkservers (and reload/restart them) then define this option and master and reload/restart it. Remember that after reload currently connected chunkservers are NOT disconnected. New AUTH_CODE will be used only when chunkservers will make new connection.

REMAP_BITS, REMAP_SOURCE_IP_CLASS, REMAP_DESTINATION_IP_CLASS

Optional IP class remapping. Remap chunkserver IP addresses with first REMAP_BITS of IP equal to first REMAP_BITS of REMAP_SOURCE_IP_CLASS. During remapping system will set first REMAP_BITS of IP address to first REMAP_BITS of REMAP_DESTINATION_IP_CLASS. (defaults are zeros which means no remap)

REPLICATIONS_DELAY_INIT

initial delay in seconds before starting replications (default is 60)

REPLICATIONS_RESPECT_TOPOLOGY

whether to make undergoal replications respect topology (default is 0)

0 - do not respect topology

1 - pick destination server at random, but then choose best source server

2 - try to find destination server in the same rack as one of the existing copies and then replicate chunk locally (in the same rack)

CREATIONS_RESPECT_TOPOLOGY

whether new chunks should be recorded with respect to topology (default is 0)

0 - do not respect topology

N (N>0) - first try to create new chunks on servers with topological distance LOWER than N from the client; if not possible, for example because of storage class, chunk servers being busy or lacking space, then try servers with distance greater or equal to N

CHUNKS_UNIQUE_MODE

avoid using same ip/rack for different chunk copies (default is 0)

0 - ignore ip and rackid (standard behaviour)

1 - avoid storing more than one copy on chunkservers using same IP number

2 - avoid storing more than one copy on chunkservers using IP number from the same rack id

CHUNKS_LOOP_MAX_CPS

Chunks loop shouldn't check more chunks per seconds than given number (default is 100000)

CHUNKS_LOOP_MIN_TIME

Chunks loop shouldn't be done in less seconds than given number (default is 300)

CHUNKS_SOFT_DEL_LIMIT

Soft maximum number of chunks to delete on one chunkserver (default is 10)

CHUNKS_HARD_DEL_LIMIT

Hard maximum number of chunks to delete on one chunkserver (default is 25)

CHUNKS_WRITE_REP_LIMIT

Maximum number of chunks to replicate to one chunkserver (default is 2,1,1,4 - see NOTES)

CHUNKS_READ_REP_LIMIT

Maximum number of chunks to replicate from one chunkserver (default is 10,5,2,5 - see NOTES)

CS_HEAVY_LOAD_THRESHOLD

Threshold for chunkserver load. (default is 150 - see NOTES)

CS_HEAVY_LOAD_RATIO_THRESHOLD

Threshold ratio for chunkserver load (default is 3.0 - see NOTES)

CS_HEAVY_LOAD_GRACE_PERIOD

Defines how long chunkservers will remain in 'grace' mode (default is 900 - see NOTES)

CS_MAINTENANCE_MODE_TIMEOUT

Maximum number of seconds server can be in maintenance mode (default value is 0 - which means 'forever')

CS_TEMP_MAINTENANCE_MODE_TIMEOUT

Maximum number of seconds server can be in "temporary" maintenance mode (server is switched to this mode whenever is stopped gracefully, after reconnection server is switched back to normal mode automatically ; default value: 1800)

CS_DAYS_TO_REMOVE_UNUSED

How many days unused (disconnected) chunkserver should be kept in master data structures (valid values: 0 - 365 ; 0 means indefinitely ; default value: 7)

ACCEPTABLE_DIFFERENCE

Maximum difference between space usage of chunkservers (deprecated, use ACCEPTABLE_PERCENTAGE_DIFFERENCE instead)

ACCEPTABLE_PERCENTAGE_DIFFERENCE

Maximum percentage difference between space usage of chunkservers (default is 1 = 1%)

PRIORITY_QUEUES_LENGTH

Length of priority queues (for endangered, undergoal etc. chunks - chunks that should be processed first - default is 1000000)

MATOCL_LISTEN_HOST

IP address to listen on for client (mount) connections (* means any)

MATOCL_LISTEN_PORT

port to listen on for client (mount) connections

SESSION_SUSTAIN_TIME

How long to sustain a disconnected client session (in seconds; default is 86400 = 1 day)

QUOTA_TIME_LIMIT

Grace period in secods for soft quota (deprecated, use QUOTA_DEFAULT_GRACE_PERIOD instead for default value or specify it individually)

QUOTA_DEFAULT_GRACE_PERIOD

Default grace period in seconds for soft quota (default is 604800 = 7 days)

ATIME_MODE

Set atime modification mode (default is 0 = always modify atime - see NOTES)

RESERVE_SPACE

Set amount of space reserved for superuser (default is 0 = do not reserve space for superuser - see NOTES)

MAX_ALLOWED_HARD_LINKS

Define limit for number of hardlinks allowed for one object (default is 32767; possible values are from 8 to 65000)

## NOTES
Chunks in master are tested in a loop. Speed (or frequency) is regulated by two options CHUNKS_LOOP_MIN_TIME and CHUNKS_LOOP_MAX_CPS. First defines minimal time between iterations of the loop and second defines maximal number of chunk tests per second. Typically at the beginning, when number of chunks is small, time is constant, regulated by CHUNK_LOOP_MIN_TIME, but when number of chunks beccomes bigger then time of loop can increase according to CHUNKS_LOOP_MAX_CPS.

Example: CHUNKS_LOOP_MIN_TIME is set to 300, CHUNKS_LOOP_MAX_CPS is set to 100000 and there is 1000000 (one million) chunks in the system. 1000000/100000 = 10, which is less than 300, so one loop iteration will take 300 seconds. With 1000000000 (one billion) chunks the system needs 10000 seconds for one iteration of the loop.

Deletion limits are defined as 'soft' and 'hard' limit. When number of chunks to delete increases from loop to loop, current limit can be temporary increased above soft limit, but never above hard limit.

Replication limits are divided into four cases:

•

first limit is for endangered chunks (chunks with only one copy)

•

second limit is for undergoal chunks (chunks with number of copies lower than specified goal)

•

third limit is for rebalance between servers with space usage around arithmetic mean

•

fourth limit is for rebalance between other servers (very low or very high space usage)

Usually first number should be grater than or equal to second, second greater than or equal to third, and fourth greater than or equal to third ( 1st >= 2nd >= 3rd <= 4th ). If one number is given, then all limits are set to this number (for backward compatibility).

Whenever chunkserver load is higher than CS_HEAVY_LOAD_THRESHOLD and CS_HEAVY_LOAD_RATIO_THRESHOLD times higher than average load, then chunkserver is switched into 'grace' mode. Chunkserver stays in grace mode for CS_HEAVY_LOAD_GRACE_PERIOD seconds.

There are five values for ATIME_MODE (all other values are treated as 0):

•

0 = Always modify atime for files, folders and symlinks.

•

1 = Always modify atime but only in case of files (do not modify atime in case of folders and symlinks).

•

2 = Modify atime only when it is lower than ctime or mtime and when current time is higher than ctime or mtime respectively, also modify atime when current atime is older than 24h. Do it for all objects during access (like "relatime" option in Linux).

•

3 = Same as above but only in case of files. In case of folders and symlinks do not modify atime.

•

4 = Never modify atime during access (like "noatime" option).

You can reserve space for superuser using RESERVE_SPACE option. You can define it as number of bytes, percent of total space, capacity of biggest chunkserver, etc.

•

\# or #B = number of bytes reserved for superuser. Standard metric prefixes can be used - SI and IEC (k,K,M,Mi,G,Gi etc.)

•

\#% or #.#% = percent of total capacity of MooseFS instance

•

\#U or #.#U = multiplies of "U" value; U is defined as maximum number of bytes currently used by a single chunkserver

•

\#C or #.#C = multiplies of "C" value; C is defined as maximum total capacity of a single chunkserver

When your network has two (or more) IP classes you may want to use one network for standard communication between MFS modules and separate network only for I/O. It can be done by setting REMAP_BITS, REMAP_SOURCE_IP_CLASS and REMAP_DESTINATION_IP_CLASS. When you set these options then master will change internally IP addresses of chunkservers and will send them as chunk locations, so clients will make connections with chunkservers using new (destination) IP for all I/O, but still communicate with master using original (source) IP. Also chunkservers will use original IP to communicate with master, but they will use new IP's to communicate between themselves during replication. Beware that all clients and chunkservers must have access to both networks, but masters, metaloggers etc. will need only access to the source network.

## COPYRIGHT
Copyright (C) 2020 Jakub Kruszona-Zawadzki, Core Technology Sp. z o.o.

This file is part of MooseFS.

MooseFS is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2 (only).

MooseFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with MooseFS; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02111-1301, USA or visit http://www.gnu.org/licenses/gpl-2.0.html

## SEE ALSO
mfsmaster(8), mfsexports.cfg(5) mfstopology.cfg(5)


mfstopology.cfg

title: mfstopology.cfg(5)

summary: MooseFS network topology definitions

text:
# mfstopology.cfg(5)

## NAME
mfstopology.cfg - MooseFS network topology definitions

## DESCRIPTION
The file mfstopology.cfg assigns IP addresses to network locations. This file is optional. If your network is very small (i.e. has just one switch) or network topology is not necessary then leave this file empty.

## SYNTAX
Syntax is:

IP_ADDRESSES LOCATION_PATH

Lines starting with # character are ignored as comments.

IP_ADDRESS can be specified in several forms:

```
*	all addresses
n.n.n.n	single IP address
n.n.n.n/b	IP class specified by network address and bits number
n.n.n.n/m.m.m.m	IP class specified by network address and mask
f.f.f.f-t.t.t.t	IP range specified by from-to addresses (inclusive)
```

LOCATION_PATH can be specified as a sequence of words separated by vertical bars.

## NOTES
If one IP belongs to more than one definition then the last definition is used.

Distance between IP numbers is defined as follows: 0 when IP numbers are the same, 1 when IP numbers are different, but paths specified by these numbers are the same. In case of different paths distance is defined as one plus maximum number of elements from both paths after common starting part.

Distances are used to sort chunkservers during read and write operations. They are also used by goal chunks replications if you enable REPLICATIONS_RESPECT_TOPOLOGY (see mfsmaster.cfg(5)). New chunks are created randomly (without using topology information). Rebalance routines may take distances into account (see CHUNKS_UNIQUE_MODE in mfsmaster.cfg(5)).

## EXAMPLES
192.168.1.0/24 US|CHICAGO|WTOWER|R1A

192.168.2.0-192.168.2.255 PL|WARSAW|GROCHOWSKA|R154

192.168.3.0/255.255.255.0 123

192.168.1.1 A|B|C

## DISTANCE EXAMPLES
Distances calculated for two different IP numbers mapped to given location paths:

d('US','DE') = 2

d('US','') = 2

d('US|PHOENIX|AT&T|RACK1','US|PHOENIX|AT&T|RACK2') = 2

d('US|PHOENIX|AT&T|RACK1','US|PHOENIX|ATM|RACK7') = 3

d('US|PHOENIX|AT&T|RACK1','US|CHICAGO|AT&T|RACK2') = 4

d('US|PHOENIX|AT&T|RACK1','US|ATM') = 4

d('US|PHOENIX|AT&T|RACK1','DE|BERLIN|ATM|RACK175') = 5

## COPYRIGHT
Copyright (C) 2020 Jakub Kruszona-Zawadzki, Core Technology Sp. z o.o.

This file is part of MooseFS.

MooseFS is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2 (only).

MooseFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with MooseFS; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02111-1301, USA or visit http://www.gnu.org/licenses/gpl-2.0.html

## SEE ALSO
mfsmaster(8), mfsmaster.cfg(5)


mfsmetalogger.cfg

package: moosefs-metalogger

title: mfsmetalogger.cfg(5)

summary: configuration file for mfsmetalogger

text:
# mfsmetalogger.cfg(5)

## NAME
mfsmetalogger.cfg - configuration file for mfsmetalogger

## DESCRIPTION
The file mfsmetalogger.cfg contains configuration of MooseFS metalogger process.

## SYNTAX
Syntax is:

OPTION = VALUE

Lines starting with # character are ignored as comments.

## OPTIONS
Configuration options:

DATA_PATH

where to store metadata files

LOCK_FILE

(deprecated) daemon lock/pid file

WORKING_USER

user to run daemon as

WORKING_GROUP

group to run daemon as (optional - if empty then default user group will be used)

SYSLOG_IDENT

name of process to place in syslog messages (default is mfsmetalogger)

LOCK_MEMORY

whether to perform mlockall() to avoid swapping out mfsmetalogger process (default is 0, i.e. no)

LIMIT_GLIBC_MALLOC_ARENAS

limit malloc arenas to given value - prevents server from using huge amount of virtual memory (Linux onty, default is 4)

DISABLE_OOM_KILLER

disable out of memory killer (Linux only, default is 1)

NICE_LEVEL

nice level to run daemon with (default is -19 if possible; note: process must be started as root to increase priority)

BACK_LOGS

number of metadata change log files (default is 50)

BACK_META_KEEP_PREVIOUS

number of previous metadata files to be kept (default is 3)

META_DOWNLOAD_FREQ

metadata download frequency in hours (default is 24, at most BACK_LOGS/2)

BIND_HOST

local address to use for master connections; default is *, i.e. default local address

MASTER_HOST

address of MooseFS master host to connect with (default is mfsmaster)

MASTER_PORT

number of MooseFS master port to connect with (default is 9420)

MASTER_RECONNECTION_DELAY

delay in seconds before trying to reconnect to master after disconnection (default is 5)

MASTER_TIMEOUT

timeout (in seconds) for master connections (default is 10)

## COPYRIGHT
Copyright (C) 2020 Jakub Kruszona-Zawadzki, Core Technology Sp. z o.o.

This file is part of MooseFS.

MooseFS is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 2 (only).

MooseFS is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with MooseFS; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02111-1301, USA or visit http://www.gnu.org/licenses/gpl-2.0.html

## SEE ALSO
mfsmetalogger(8)