-
Notifications
You must be signed in to change notification settings - Fork 6
/
MooseFS-2-0-Users-Manual.tex
2656 lines (1988 loc) · 138 KB
/
MooseFS-2-0-Users-Manual.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
% Copyright (c) 2014-2017 Piotr Robert Konopelko, 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
\documentclass[a4paper,11pt,english]{report}
\usepackage{url}
\usepackage{hyperref}
\usepackage{fullpage}
\usepackage{parskip}
\usepackage{graphicx}
\usepackage{xcolor}
\usepackage{listings}
\lstset{
language=bash,
basicstyle=\ttfamily\scriptsize,
showstringspaces=false,
commentstyle=\color{black},
keywordstyle=\color{black},
breakatwhitespace=false,
breaklines=true,
showspaces=false,
tabsize=4
}
\def\code#1{\texttt{#1}}
\newenvironment{copyrightnotice}
{\begingroup
\footnotesize
\setlength{\parindent}{0pt}
\setlength{\parskip}{\baselineskip}}
{\endgroup}
% ------------------------------------------------------------------------
\begin{document}
\renewcommand{\labelitemi}{$\bullet$}
\renewcommand{\labelitemii}{$\circ$}
\renewcommand{\labelitemiii}{$\bullet$}
\renewcommand{\labelitemiv}{$\circ$}
\begin{titlepage}
\begin{center}
\includegraphics[width=0.2\textwidth]{images/moosefs.png}\\[1cm]
% Title
{ \huge \bfseries MooseFS 2.0
User's Manual \\[0.4cm] }
\textsc{Core Technology} Development \& Support Team
\vfill
% Bottom of the page
{\large \today}
\end{center}
\end{titlepage}
% Copyright page
\begin{copyrightnotice}
\begin{flushleft}
Copyright \textcopyright{} 2014-\the\year
\hfill
\textsc{v. 1.4.3}\\ % DOCUMENTVERSION
Piotr Robert Konopelko, \textsc{Core Technology} Development \& Support Team.
\emph{Proofread by}
Agata Kruszona-Zawadzka \\
\emph{Coordination \& layout by} Piotr Robert Konopelko.
Please send corrections to \href{mailto:[email protected]}{Piotr Robert Konopelko} -- [email protected].
\bigskip
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 \url{http://www.gnu.org/licenses/gpl-2.0.html}
\end{flushleft}
\end{copyrightnotice}
\vfill
\tableofcontents
\chapter{About MooseFS}
MooseFS is a fault-tolerant distributed file system. It spreads data over several physical locations (servers), which are visible to user as one resource. For standard file operations MooseFS acts as any other Unix-alike filesystem:
\begin{itemize}
\item Hierarchical structure (directory tree)
\item Stores POSIX file attributes (permissions, last access and modification times)
\item Supports special files (block and character devices, pipes and sockets)
\item Symbolic links (file names pointing to target files, not necessarily on MooseFS) and hard links (different names of files that refer to the same data on MooseFS)
\item Access to the file system can be limited based on IP address and/or password
\end{itemize}
\bigskip
Distinctive features of MooseFS are:
\begin{itemize}
\item High reliability (several copies of the data can be stored on separate physical machines)
\item Capacity is dynamically expandable by adding new computers/disks
\item Deleted files are retained for a configurable period of time (a file system level "trash bin")
\item Coherent snapshots of files, even while the file is being written/accessed
\end{itemize}
\section{Architecture}
MooseFS consists of four components:
\begin{enumerate}
\item Managing servers (\code{master server}s) -- In Community Edition one machine, in Pro any number of machines managing the whole filesystem, storing metadata for every file (information on size, attributes and file location(s), including all information about non-regular files, i.e. directories, sockets, pipes and devices).
\item Data servers (\code{chunk servers}) -- any number of commodity servers storing files' data and synchronizing it among themselves (if a certain file is supposed to exist in more than one copy).
\item Metadata backup server(s) (\code{metalogger server}) -- any number of servers, all of which store metadata changelogs and periodically download main metadata file.
In CE version machine with metalogger can be easily set up as a master in case of main master failure.
In Pro version metalogger can be set up to provide an additional level of security.
\item Client computers that access (\code{mount}) the files in MooseFS -- any number of machines using \code{mfsmount} process to communicate with the managing server (to receive and modify file metadata) and with chunkservers (to exchange actual file data).
\end{enumerate}
\bigskip
\code{mfsmount} is based on the FUSE\footnote{You can read more about FUSE at \url{http://fuse.sourceforge.net}} mechanism (Filesystem in USErspace), so MooseFS is available on every Operating System with a working FUSE implementation (Linux, FreeBSD, MacOS X, etc.)
\bigskip
\begin{center}
\includegraphics[width=0.8\textwidth]{images/read_mfs.png}\\[1cm]
\end{center}
\vfill
\begin{center}
\includegraphics[width=0.8\textwidth]{images/write_mfs.png}\\[1cm]
\end{center}
Metadata is stored in the memory of the managing server and simultaneously saved to disk (as a periodically updated binary file and immediately updated incremental logs). The main binary file as well as the logs are synchronized to the metaloggers (if present) and to spare master servers in Pro version.
File data is divided into fragments (chunks) with a maximum size of 64MiB each. Each chunk is itself a file on selected disks on data servers (chunkservers).
High reliability is achieved by configuring as many different data servers as appropriate to assure the "\code{goal}" value (number of copies to keep) set for the given file.
\section{How does the system work}
All file operations on a client computer that has mounted MooseFS are exactly the same as they would be with other file systems. The operating system's kernel transfers all file operations to the FUSE module, which communicates with the \code{mfsmount} process. The \code{mfsmount} process communicates through the network subsequently with the managing server and data servers (chunk servers). This entire process is fully transparent to the user.\\\\
\code{mfsmount} communicates with the managing server every time an operation on file metadata is required:
\begin{itemize}
\item creating files
\item deleting files
\item reading directories
\item reading and changing attributes
\item changing file sizes
\item at the start of reading or writing data
\item on any access to special files on \code{MFSMETA}
\end{itemize}
\bigskip
\code{mfsmount} uses a direct connection to the data server (chunk server) that stores the relevant chunk of a file. When writing a file, after finishing the write process the managing server receives information from \code{mfsmount} to update a file's length and the last modification time.
Furthermore, data servers (chunk servers) communicate with each other to replicate data in order to achieve the appropriate number of copies of a file on different machines.
\section{Fault tolerance}
% Add more information
Administrative commands allow the system administrator to specify the "\code{goal}", or number of copies that should be maintained, on a per-directory or per-file level. Setting the goal to more than one and having more than one data server will provide fault tolerance. When the file data is stored in many copies (on more than one data server), the system is resistant to failures or temporary network outages of a single data server.
This of course does not refer to files with the "\code{goal}" set to 1, in which case the file will only exist on a single data server irrespective of how many data servers are deployed in the system.\\
Exceptionally important files may have their \code{goal} set to a number higher than two, which will allow these files to be resistant to a breakdown of more than one server at the same time.\\
In general the setting for the number of copies available should be one more than the anticipated number of inaccessible or out-of-order servers.\\
In the case where a single data server experiences a failure or disconnection from the network, the files stored within it that had at least two copies, will remain accessible from another data server. The data that is now 'under its goal' will be replicated on another accessible data server to again provide the required number of copies.\\
It should be noted that if the number of available servers is lower than the "\code{goal}" set for a given file, the required number of copies cannot be preserved. Similarly if there are the same number of servers as the currently set goal and if a data server has reached 100\% of its capacity, it will be unable to hold a copy of a file that is now below its goal due to another data server going offline. In these cases a new data server should be connected to the system as soon as possible in order to maintain the desired number of copies of the file.\\
A new data server can be connected to the system at any time. The new capacity will immediately become available for use to store new files or to hold replicated copies of files from other data servers.\\
Administrative utilities exist to query the status of the files within the file system to determine if any of the files are currently below their goal (set number of copies). This utility can also be used to alter the goal setting as required.\\
The data fragments stored in the chunks are versioned, so re-connecting a data server with older copy of data (i.e. if it had been offline for a period of time), will not cause the files to become incoherent. The data server will synchronize itself to hold the current versions of the chunks, where the obsolete chunks will be removed and the free space will be reallocated to hold the new chunks.\\
Failures of a client machine (that runs the \code{mfsmount} process) will have no influence on the coherence of the file system or on the other clients' operations. In the worst case scenario the data that has not yet been sent from the failed client computer may be lost.
\section{Platforms}
MooseFS is available on every Operating System with a working FUSE implementation:
\begin{itemize}
\item Linux (Linux 2.6.14 and up have FUSE support included in the official kernel)
\item FreeBSD
\item OpenSolaris
\item MacOS X
\end{itemize}
\bigskip
The master server, metalogger server and chunkservers can also be run on Solaris or Windows with Cygwin. Unfortunately without FUSE it won't be possible to mount the filesystem within these operating systems.
\chapter{Moose File System Requirements}
\section{Network requirements}
MooseFS requires TCP/IP network. The faster the network is, the better is performance. It is recommended to connect all servers to the same switch or at least try to minimize network latencies, because they may have significant impact on performance.
MooseFS requires the following ports to be open (it can be configured in appropriate configuration files):
\begin{itemize}
\item \code{9419..9421} -- Master Server(s)
\item \code{9422} -- Chunkservers
\item \code{9425} -- CGI Server
\end{itemize}
\section{Requirements for Master Servers}
As the managing server (master) is a crucial element of MooseFS, it should be installed on a machine which guarantees high stability and access requirements which are adequate for the whole system. It is advisable to use a server with a redundant power supply, ECC memory, and disk array RAID1/RAID5/RAID10. The managing server OS has to be POSIX compliant (systems verified so far: Linux, FreeBSD, MacOS X and OpenSolaris).
\subsection{CPU}
Because Master Server is a single-threaded process, it is recommended to use modern CPU with high clock (e.g. 3.7 GHz) and small number of cores (e.g. 4) -- especially in MooseFS instances which handle a lot of small files.
Additionally, disabling CPU power management in BIOS (or enable mode like "maximum performance") may have positive impact on efficiency.
You can compare CPUs on the following website -- please pay attention to "single-thread points": \code{\url{https://www.cpubenchmark.net/singleThread.html}}.
\subsection{RAM size}
The most important factor in sizing requirements for the Master Server machine is RAM, as the full file system structure is cached in RAM for speed. The Master Server should have approximately 300-350 MiB of RAM allocated to handle 1 million objects (files, directories, pipes, sockets, ...).
\underline{Example}:
\begin{itemize}
\item Leader Master RAM usage: \code{20 GiB} (\code{21 017 505 792} Bytes exactly)
\item "All FS objects" (from MFS CGI): \code{67 552 270}
\item \code{21 017 505 792 / 67 552 270 = $\sim$311.13} Bytes per one object
\end{itemize}
\subsection{HDD free space}
The necessary size of HDD depends both on the number of files and chunks used (main metadata file) and on the number of operations made on the files (metadata changelog); for example the space of 20 GiB is enough for storing information for 25 million files and for changelogs to be kept for up to 50 hours.
You can calculate the minimum amount of space we recommend using the following formula:
\begin{itemize}
\item \code{RAM} -- amount of RAM
\item \code{BACK\_LOGS} -- number of metadata change log files, default is 50 (from \code{/etc/mfs/mfsmaster.cfg})
\item \code{BACK\_META\_KEEP\_PREVIOUS} -- number of previous metadata files to be kept (default is 1) (also from \code{/etc/mfs/mfsmaster.cfg})
\end{itemize}
\bigskip
\underline{The formula}: \\
\code{SPACE = RAM * (BACK\_META\_KEEP\_PREVIOUS + 2) + 1 * (BACK\_LOGS + 1) [GiB]}
\bigskip
(If default values from \code{/etc/mfs/mfsmaster.cfg} are used, it is \code{RAM * 3 + 51 [GiB]})
The value \code{1} (before multiplying by \code{BACK\_LOGS + 1}) is an estimation of size used by one \code{changelog.[number].mfs} file. On highly loaded MooseFS instance it uses a bit less than 1 GB.
\underline{Example}: \\
If you have 128 GiB of RAM, using the formula above, you should reserve for \code{/var/lib/mfs}:
128*3 + 51 = 384 + 51 = \textbf{435 GiB minimum}.
\section{Requirements for Metalogger(s)}
MooseFS metalogger simply gathers metadata backups from the MooseFS Master Server -- so the hardware requirements are not higher than for the Master Server itself; it needs about the same disk space. Similarly to the Master Server -- the OS has to be POSIX compliant (Linux, FreeBSD, Mac OS X, OpenSolaris, etc.).\\
MooseFS Metalogger should have at least the same amount of HDD space (\textbf{especially the free space in \code{/var/lib/mfs}!}) as the main Master Server.
If you would like to use the Metalogger as a Master Server in case of the main Master's failure, the Metalogger machine should have at least the same amount of RAM as the main Master Server.
\section{Requirements for Chunkservers}
Chunkservers, like other MooseFS machines have to have POSIX compliant OS.
\subsection{CPU}
MooseFS Chunkserver is a multi-threaded process, so the best choice is to have a CPU with a number of cores.
\subsection{RAM size}
MooseFS Chunkserver uses approximately 250 MiB of RAM allocated to handle 1 million chunks.
\underline{Example}:
\begin{itemize}
\item Chunkserver RAM usage: \code{661 MiB}
\item Chunks stored on this Chunkserver (from MFS CGI): \code{3 275 062}
\item \code{(661 * $2^{20}$) / 3 275 062 = $\sim$211.63} Bytes per one chunk
\end{itemize}
\subsection{HDD space}
Chunkserver machines should have appropriate disk space (dedicated exclusively for MooseFS). Typical and recommended usage is to create one partition on each HDD, mount them and enter paths to mounted partitions in \code{/etc/mfs/mfshdd.cfg}.
Minimal configuration should start from several gigabytes of storage space (only disks with more than 256 MB and Chunkservers reporting more than 1 GB of total free space are accessible for new data).
\section{Requirements for Clients / Mounts}
\code{mfsmount} requires FUSE to work; FUSE is available on several operating systems: Linux, FreeBSD, OpenSolaris and MacOS X, with the following notes:
\begin{itemize}
\item In case of Linux a kernel module with API 7.8 or later is required (it can be checked with dmesg command -- after loading kernel module there should be a line fuse init (API version 7.8)). It is available in fuse package 2.6.0 (or later) or in Linux kernel 2.6.20 (or later). Due to some minor bugs, the newer module is recommended (fuse 2.7.2 or Linux 2.6.24, although fuse 2.7.x standalone doesn't contain getattr/write race condition fix).
\item In case of FreeBSD we recommed using fuse-freebsd\footnote{\url{https://github.com/glk/fuse-freebsd}}, which is a successor to fuse4bsd.
\item For MacOSX we recommend using OSXFUSE\footnote{\url{http://osxfuse.github.com}}, which is a successor to MacFUSE and has been tested on MacOSX 10.6, 10.7, 10.8, 10.9 and 10.11.
\end{itemize}
\chapter{Installing MooseFS 2.0}
This is a Very Quick Start Guide describing basic MooseFS 2.0 installation in configuration of two Master Servers and three Chunkservers.
Please note that complete installation process is described in "MooseFS 2.0 Step by Step Tutorial".
For the sake of this document, it's assumed that your machines have following IP addresses:
\begin{itemize}
\item Master servers: 192.168.1.1, 192.168.1.2
\item Chunkservers: 192.168.1.101, 192.168.1.102 and 192.168.1.103
\item Users' computers (clients): 192.168.2.x
\end{itemize}
\bigskip
\bigskip
\bigskip
In this tutorial it is assumed that you have MooseFS 2.0 Pro version. If you use Community Edition, please remove '\code{-pro}' from packages names.
\bigskip
In this tutorial it is also assumed that you have Ubuntu/Debian installed on your machines. If you have another distribution, please use appropriate package manager instead of \code{apt}.
\section{Configuring DNS Server}
Before you start installing MooseFS, you need to have working DNS. It's needed for MooseFS to work properly with several master servers, because DNS can resolve one host name as more than one IP address. \\
All IPs of machines which will be master servers must be included in DNS configuration file and resolved as "\code{mfsmaster}" (or any other selected name), e.g.:
\begin{lstlisting}[caption={DNS entries}]
mfsmaster IN A 192.168.1.1 ; address of first master server
mfsmaster IN A 192.168.1.2 ; address of second master server
\end{lstlisting}
More information about configuring DNS server is included in supplement to "MooseFS Step by Step Tutorial".
\section{Adding repositories}
Before installing MooseFS you need to add MooseFS Official Supported Repositories to your system.
\subsection{Ubuntu / Debian}
First, add the key:
\begin{lstlisting}[caption={Adding the repo key}]
# wget -O - http://ppa.moosefs.com/moosefs.key | apt-key add -
\end{lstlisting}
\bigskip
Then add the appropriate entry in \code{/etc/apt/sources.list}:
\begin{itemize}
\item For Ubuntu 14.04 Trusty: \\
\code{deb http://ppa.moosefs.com/moosefs-2/apt/ubuntu/trusty trusty main}
\item For Ubuntu 12.04 Precise: \\
\code{deb http://ppa.moosefs.com/moosefs-2/apt/ubuntu/precise precise main}
\item For Ubuntu 10.10 Maverick: \\
\code{deb http://ppa.moosefs.com/moosefs-2/apt/ubuntu/maverick maverick main}
\item For Debian 7.0 Wheezy: \\
\code{deb http://ppa.moosefs.com/moosefs-2/apt/debian/wheezy wheezy main}
\item For Debian 6.0 Squeeze: \\
\code{deb http://ppa.moosefs.com/moosefs-2/apt/debian/squeeze squeeze main}
\item For Debian 5.0 Lenny: \\
\code{deb http://ppa.moosefs.com/moosefs-2/apt/debian/lenny lenny main}
\end{itemize}
\bigskip
After that do: \\
\code{\# apt-get update}
\subsection{RedHat / CentOS (EL7)}
Red Hat 7 familiy OS use \code{systemd} Linux system and service manager to start processes. To use systemctl command to start MooseFS processes use this steps to add \code{systemd} repository.\\
Add the appropriate key to package manager:
\begin{lstlisting}[caption={Adding the repo key}]
# curl "http://ppa.moosefs.com/RPM-GPG-KEY-MooseFS" > /etc/pki/rpm-gpg/RPM-GPG-KEY-MooseFS
\end{lstlisting}
Next you need to add the repository entry to yum repo:
\begin{lstlisting}[caption={Adding MooseFS repo}]
# curl "http://ppa.moosefs.com/MooseFS-2-el7.repo" > /etc/yum.repos.d/MooseFS.repo
# yum update
\end{lstlisting}
\subsection{RedHat / CentOS (EL6)}
Red Hat 6 family OS use \code{SysV init} runlevel system to start processes. To use service command to start MooseFS processes use this steps to add SysV repository.\\
Add the appropriate key to package manager:
\begin{lstlisting}[caption={Adding the repo key}]
# curl "http://ppa.moosefs.com/RPM-GPG-KEY-MooseFS" > /etc/pki/rpm-gpg/RPM-GPG-KEY-MooseFS
\end{lstlisting}
Next you need to add the repository entry to yum repo:
\begin{lstlisting}[caption={Adding the MooseFS repo}]
# curl "http://ppa.moosefs.com/MooseFS-2-el6.repo" > /etc/yum.repos.d/MooseFS.repo
# yum update
\end{lstlisting}
\subsection{Apple MacOS X}
It's possible to run all components of the system on Mac OS X systems, but most common scenario would be to run the client (\code{mfsmount}) that enables Mac OS X users to access resources available in MooseFS infrastructure.
In case of MacOS X -- since there's no default package manager -- we release \code{.pkg} files containing only binaries without any startup scripts, that normally are available in Linux packages.
To install MooseFS on Mac please follow these steps:
\begin{itemize}
\item download and install FUSE for Mac OS X package from \\
\code{http://osxfuse.github.io}
\item download and install MooseFS packages from \\
\code{http://ppa.moosefs.com/moosefs-2/osx/}
\end{itemize}
You should be able to mount MooseFS filesystem in \code{/mnt/mfs} issuing the following command:
\code{\$ sudo mfsmount /mnt/mfs}
If you've exported filesystem with additional options like password protection, you should include those options in \code{mfsmount} invocation as in documentation.
\section{Differences in package names between Pro and CE version}
The packages in MooseFS 2.0 Pro version are named according to following pattern:
\begin{itemize}
\item \code{moosefs-pro-master}
\item \code{moosefs-pro-metalogger}
\item \code{moosefs-pro-chunkserver}
\item \code{moosefs-pro-client}
\item \code{moosefs-pro-cli}
\item \code{moosefs-pro-cgi}
\item \code{moosefs-pro-cgiserv}
\item \code{moosefs-pro-netdump}
\item \code{moosefs-pro-supervisor}
\end{itemize}
\bigskip
In MooseFS 2.0 Community Edition (CE) the packages are named according to the following pattern:
\begin{itemize}
\item \code{moosefs-master}
\item \code{moosefs-metalogger}
\item \code{moosefs-chunkserver}
\item \code{moosefs-client}
\item \code{moosefs-cli}
\item \code{moosefs-cgi}
\item \code{moosefs-cgiserv}
\item \code{moosefs-netdump}
\end{itemize}
\section{MooseFS Master Server(s) installation}
Install package \code{moosefs-pro-master} by running the following command:
\underline{For Debian OS family}:
\begin{lstlisting}
# apt-get install moosefs-pro-master
\end{lstlisting}
\underline{For RedHat OS family}:
\begin{lstlisting}
# yum install moosefs-pro-master
\end{lstlisting}
Now, set MooseFS Master Server basic configuration:
\begin{lstlisting}
# cd /etc/mfs
# cp mfsmaster.cfg.dist mfsmaster.cfg
# cp mfsexports.cfg.dist mfsexports.cfg
\end{lstlisting}
File \code{mfsexports.cfg} specifies which users' computers can mount the file system and with what privileges. For example, to specify that only machines addressed as \code{192.168.2.x} can use the whole structure of MooseFS resources (\code{/}) in read/write mode, in the first line which is not commented out change the asterisk (\code{*}) to \code{192.168.2.0/24}, so that you'll have:
\begin{lstlisting}
192.168.2.0/24 / rw,alldirs,maproot=0
\end{lstlisting}
Now, if you use MooseFS Pro, place proper \code{mfslicence.bin} file into \code{/etc/mfs} directory. This file \textbf{must} be available on \textbf{all} Master Servers.
At this point it is possible to run the MooseFS Master Server:
\begin{lstlisting}
# mfsmaster start
\end{lstlisting}
If you use \code{SysV} init script manager, which is by default available in Debian, Ubuntu and RedHat 6 family operating systems, you can also start Master by issuing the following command:
\begin{lstlisting}
# service moosefs-pro-master start
\end{lstlisting}
To start MooseFS Master Server with latest \code{systemd} Linux system and service manager, which is available in RedHat 7 family operating systems, use this command:
\begin{lstlisting}
# systemctl start moosefs-pro-master.service
\end{lstlisting}
You need to repeat these steps on each machine intended for running MooseFS Master Server (in this example -- on \code{192.168.1.1} and \code{192.168.1.2}).
You can also find more detailed description how to add Master Followers in \textbf{MooseFS Upgrade Guide - Chapter 6: Adding master follower(s) server(s) procedure} (Pro only).
\section{MooseFS CGI Monitor, CGI Server and Command Line Interface installation}
MooseFS CGI Monitor and MooseFS CGISERV can be installed on any machine, but good practice tells that it should be installed on every Master Server.
MooseFS Command Line Interface (CLI) tool allows you to see various information about MooseFS status. The \code{mfscli} with \code{-SIN} option displays basic info similar to the "Info" tab in CGI. To install CGI, CGISERV and CLI, use the following commands.
\underline{For Debian OS family}:
\begin{lstlisting}
# apt-get install moosefs-pro-cgi
# apt-get install moosefs-pro-cgiserv
# apt-get install moosefs-pro-cli
\end{lstlisting}
Set \code{MFSCGISERV\_ENABLE} variable to \code{true} in file \code{/etc/default/mfs-cgiserv} to configure \code{mfscgiserv} autostart.
\underline{For RedHat OS family}:
\begin{lstlisting}
# yum install moosefs-pro-cgi
# yum install moosefs-pro-cgiserv
# yum install moosefs-pro-cli
\end{lstlisting}
Run MooseFS CGI Monitor with \code{SysV}:
\begin{lstlisting}
# service moosefs-pro-cgiserv start
\end{lstlisting}
Run MooseFS CGI Monitor with \code{systemd}:
\begin{lstlisting}
# systemctl start moosefs-pro-cgiserv.service
\end{lstlisting}
MooseFS CGI Monitor website should now be available at \url{http://192.168.1.1:9425} address(for the moment there would be no data about chunk servers).
\section{Chunk servers installation}
\underline{For Debian OS family}:
\begin{lstlisting}
# apt-get install moosefs-pro-chunkserver
\end{lstlisting}
\underline{For RedHat OS family}:
\begin{lstlisting}
# yum install moosefs-pro-chunkserver
\end{lstlisting}
Now you need to prepare basic configuration files for the \code{mfschunkserver}:
\begin{lstlisting}
# cd /etc/mfs
# cp mfschunkserver.cfg.dist mfschunkserver.cfg
# cp mfshdd.cfg.dist mfshdd.cfg
\end{lstlisting}
In the \code{mfshdd.cfg} file you'll give locations in which you have mounted hard drives/partitions designed for the chunks of the system. It is recommended that they are used exclusively for the MooseFS -- this is necessary to manage the free space properly. For example if you'll use \code{/mnt/mfschunks1} and \code{/mnt/mfschunks2} locations, add these two lines to \code{mfshdd.cfg} file:
\begin{lstlisting}
/mnt/mfschunks1
/mnt/mfschunks2
\end{lstlisting}
Before you start chunkserver, make sure that the user \code{mfs} has rights to write in the mounted partitions (which is necessary to create a .lock file):
\begin{lstlisting}
# chown -R mfs:mfs /mnt/mfschunks1
# chown -R mfs:mfs /mnt/mfschunks2
\end{lstlisting}
At this moment you are ready to start the chunk server:
For \code{SysV} init script system
\begin{lstlisting}
# service moosefs-pro-chunkserver start
\end{lstlisting}
For \code{systemd} Linux system and service manager
\begin{lstlisting}
# systemctl start moosefs-pro-chunkserver.service
\end{lstlisting}
\bigskip
\bigskip
You need to repeat these steps on each machine intended for running MooseFS Chunkserver (in this example -- on \code{192.168.1.101}, \code{192.168.1.102} and \code{192.168.1.103}.
Now at \url{http://192.168.1.1:9425} full information about the system is available, including the master server and chunk servers.
\section{MooseFS Clients installation}
MooseFS client uses \code{FUSE} library. During installation process, your operating system also downloads and installs \code{FUSE} library if it is not installed.
\underline{Debian OS family}:
\begin{lstlisting}
# apt-get install moosefs-pro-client
\end{lstlisting}
\underline{RedHat OS family}:
\begin{lstlisting}
# yum install moosefs-pro-client
\end{lstlisting}
Let's assume that you want to mount the MooseFS share in a \code{/mnt/mfs} folder on a client's machine. Issue the following commands:
\begin{lstlisting}
# mkdir -p /mnt/mfs
# mfsmount /mnt/mfs -H mfsmaster
\end{lstlisting}
Now after running the \code{df -h | grep mfs} command you should get information similar to this:
\begin{lstlisting}
/storage/mfschunks/mfschunks1
2.0G 69M 1.9G 4% /mnt/mfschunks1
/storage/mfschunks/mfschunks2
2.0G 69M 1.9G 4% /mnt/mfschunks2
mfs#mfsmaster:9421
3.2G 0 3.2G 0% /mnt/mfs
\end{lstlisting}
You need to repeat these steps on each machine intended to be MooseFS 2.0 Client (in this example -- on \code{192.168.2.x}.
To enable MooseFS Client automount during boot, first of all check if the \code{fuse} and \code{fuse-libs} packages are installed. If \code{fuse} and \code{fuse-libs} packages are installed, add similar entry to the following one in \code{/etc/fstab}:
\begin{lstlisting}
mfsmount /mnt/mfs fuse defaults,mfsmaster=mfsmaster.example.lan,mfsport=9421 0 0
\end{lstlisting}
If MooseFS Client has to be mounted on the same machine that MooseFS Master Server runs, please put the following \code{fstab} entry instead of the one listed above:
\begin{lstlisting}
mfsmount /mnt/mfs fuse defaults,mfsdelayedinit,mfsmaster=mfsmaster.example.lan,mfsport=9421 0 0
\end{lstlisting}
\newpage
\section{Enabling MooseFS services during OS boot}
Each operating system has it's own method to manage services start during boot. Below you can find a few examples of enabling MooseFS autostart in supported operating systems.
\subsection{RedHat / Centos (EL6)}
\underline{MooseFS Chunkserver}:
To enable MooseFS Chunkserver autostart during OS boot, use \code{chkconfig} command like in example below:
\begin{lstlisting}
chkconfig moosefs-chunkserver on
\end{lstlisting}
\underline{MooseFS Master Server}:
To enable MooseFS Master Server autostart during OS boot, use \code{chkconfig} command like in example below:
\begin{lstlisting}
chkconfig moosefs-master on
\end{lstlisting}
\underline{MooseFS Client}:
To enable MooseFS Client automount during boot, first of all check if the \code{fuse} and \code{fuse-libs} packages are installed:
\begin{lstlisting}
# rpm -qa | grep fuse
fuse-2.8.3-4.el6.x86_64
fuse-libs-2.8.3-4.el6.x86_64
\end{lstlisting}
If \code{fuse} and \code{fuse-libs} packages are installed, add similar entry to the following one in \code{/etc/fstab}:
\begin{lstlisting}
mfsmount /mnt/mfs fuse defaults,mfsmaster=mfsmaster.example.lan,mfsport=9421 0 0
\end{lstlisting}
If MooseFS Client has to be mounted on the same machine that MooseFS Master Server runs, please put the following \code{fstab} entry instead of the one listed above:
\begin{lstlisting}
mfsmount /mnt/mfs fuse defaults,mfsdelayedinit,mfsmaster=mfsmaster.example.lan,mfsport=9421 0 0
\end{lstlisting}
\subsection{RedHat / Centos (EL7)}
In operating systems with \code{systemd}, use \code{systemctl} command to manage init processes at boot:
\underline{MooseFS Chunkserver}:
To enable MooseFS Chunkserver autostart during OS boot:
\begin{lstlisting}
systemctl enable moosefs-chunkserver.service
\end{lstlisting}
\underline{MooseFS Master Server}:
To enable MooseFS Master Server autostart during OS boot:
\begin{lstlisting}
systemctl enable moosefs-master.service
\end{lstlisting}
\underline{MooseFS Client}:
To enable MooseFS Client automount during boot, first of all check if the \code{fuse} and \code{fuse-libs} packages are installed:
\begin{lstlisting}
# rpm -qa | grep fuse
fuse-2.9.2-6.el7.x86_64
fuse-libs-2.9.2-6.el7.x86_64
\end{lstlisting}
If \code{fuse} and \code{fuse-libs} packages are installed, add similar entry to the following one in \code{/etc/fstab}:
\begin{lstlisting}
mfsmount /mnt/mfs fuse mfsmaster=mfsmaster.example.lan,mfsport=9421 0 0
\end{lstlisting}
If MooseFS Client has to be mounted on the same machine that MooseFS Master Server runs, please put the following \code{fstab} entry instead of the one listed above:
\begin{lstlisting}
mfsmount /mnt/mfs fuse defaults,mfsdelayedinit,mfsmaster=mfsmaster.example.lan,mfsport=9421 0 0
\end{lstlisting}
\subsection{Debian / Ubuntu}
This method works in Debian 6, Debian 7, Ubuntu 12, Ubuntu 14.
\underline{MooseFS Chunkserver}:
To enable MooseFS Chunkserver autostart during OS boot, find \code{/etc/default/moosefs-chunkserver} file and change \code{MFSCHUNKSERVER\_ENBLE} variable to \code{true}:
\begin{lstlisting}
MFSCHUNKSERVER_ENABLE=true
\end{lstlisting}
\underline{MooseFS Master}:
To enable MooseFS Master Server autostart during OS boot, edit \code{/etc/default/moosefs-master} file and change \code{MFSMASTER\_ENBLE} variable to \code{true}:
\begin{lstlisting}
MFSMASTER_ENABLE=true
\end{lstlisting}
\underline{MooseFS Client}:
To enable MooseFS Client automount during boot, first of all check if the \code{fuse} and \code{fuse-libs} packages are installed. If \code{fuse} and \code{fuse-libs} packages are installed, add similar entry to the following one in \code{/etc/fstab}:
\begin{lstlisting}
mfsmount /mnt/mfs fuse mfsmaster=mfsmaster.example.lan,mfsport=9421 0 0
\end{lstlisting}
If MooseFS Client has to be mounted on the same machine that MooseFS Master Server runs, please put the following \code{fstab} entry instead of the one listed above:
\begin{lstlisting}
mfsmount /mnt/mfs fuse defaults,mfsdelayedinit,mfsmaster=mfsmaster.example.lan,mfsport=9421 0 0
\end{lstlisting}
\subsection{FreeBSD}
\underline{MooseFS Chunkserver}:
To enable MooseFS Chunkserver autostart during OS boot, add an entry to \code{/etc/rc.conf}:
\begin{lstlisting}
mfschunkserver_enable="YES"
\end{lstlisting}
\underline{MooseFS Master}:
To enable MooseFS Chunkserver autostart during OS boot, add entry to \code{/etc/rc.conf}:
\begin{lstlisting}
mfsmaster_enable="YES"
\end{lstlisting}
\underline{MooseFS Client}:
To enable MooseFS Client automount during boot add the following entry in \code{/boot/loader.conf} to let FreeBSD load \code{fuse} module during boot:
\begin{lstlisting}
fuse_load="YES"
\end{lstlisting}
And add the entry in \code{/etc/fstab}:
\begin{lstlisting}
mfsmount_magic /mnt/mfs moosefs rw,mfsmaster=mfsmaster,mountprog=/usr/local/bin/mfsmount,late 0 0
\end{lstlisting}
\newpage
\section{Basic MooseFS use}
Create \code{folder1} in \code{/mnt/mfs}, in which you store files in one copy (setting \code{goal=1}):
\begin{lstlisting}
mkdir -p /mnt/mfs/folder1
\end{lstlisting}
and \code{folder2}, in which you store files in two copies (setting \code{goal=2}):
\begin{lstlisting}
mkdir -p /mnt/mfs/folder2
\end{lstlisting}
The number of copies for the folder is set with the \code{mfssetgoal -r} command:
\begin{lstlisting}
# mfssetgoal -r 1 /mnt/mfs/folder1
/mnt/mfs/folder1:
inodes with goal changed: 0
inodes with goal not changed: 1
inodes with permission denied: 0
# mfssetgoal -r 2 /mnt/mfs/folder2
/mnt/mfs/folder2:
inodes with goal changed: 0
inodes with goal not changed: 1
inodes with permission denied: 0
\end{lstlisting}
\section{Stopping MooseFS}
In order to safely stop the MooseFS cluster you have to perform the following steps:
\begin{itemize}
\item Unmount the file system on all machines using umount command (in our example it would be: \code{umount /mnt/mfs})
\item Stop the Chunk Servers processes:\\
For \code{SysV}: \code{service moosefs-pro-chunkserver stop}\\
For \code{systemd}: \code{systemctl stop moosefs-pro-chunkserver.service}
\item Stop the Master Server processes (starting from the FOLLOWER, you shuould stop the LEADER Master Server as the last one):\\
For \code{SysV}: \code{service moosefs-pro-master stop}\\
For \code{systemd}: \code{systemctl stop moosefs-pro-master.service}
\item Stop the Metalogger process:\\
For \code{SysV}: \code{service moosefs-pro-metalogger stop}\\
For \code{systemd}: \code{systemctl stop moosefs-pro-metalogger.service}
\end{itemize}
\chapter{Troubleshooting}
\section{Metadata save}
Sometimes MFS master server freezes during the metadata save. To overcome this problem you should change one setting in your system. On your master machines, you should enable overcommit memory setting by issuing the following command as root:
\begin{lstlisting}
# echo 1 > /proc/sys/vm/overcommit_memory
\end{lstlisting}
To do it permanently, you can add the following line to your \code{/etc/sysctl.conf} file (it works only on Linux):
\begin{lstlisting}
vm.overcommit_memory=1
\end{lstlisting}
More detail about the reasons for this behavior:\\
Master server performs a fork operation, effectively spawning another process to save metadata to disk. Theoretically, when you fork a process, the process memory is copied. In real life it is done the lazy way -- the memory is marked, so that if any changes are to occur, a block with changes is copied as needed, but only then. Now, if you fork a process that has 180GB of memory in use, the system can "just do it", or check if it has 180GB of free memory and reserve it for the forked "child", and only then do it and, when it doesn't have enough memory, the fork operation fails -- this is the case in Linux, so actually saving metadata is done in the main process, because fork operation failed.
This behavior differs between systems and even between distributions of one system.
It is safe to enable overcommit memory (the "just do it" way) with mfsmaster, because the forked process is short lived. It terminates as soon as it manages to save metadata, and during the time that it works, there are usually not that many changes to the main process' memory, so the amount of additional RAM needed is relatively small.
Alternatively, you can add huge (at least equal to the amount of physical RAM or even more) amounts of swap space on your master servers -- then the fork should succeed, because it should always find the needed memory space in your swap.
\section{Master metadata restore from metaloggers}
MooseFS Community Edition have only one master, but can have several metaloggers deployed for backup. If for some reason you loose all metadata files and changelogs from master server you can use data form metalogger to restore your data. To start dealing with recovery first you need to transfer all data stored on metalogger in \code{/var/lib/mfs} to master metadata folder. Files on metalogger will have \code{\_ml\_} prefix prepended to the filenames. After all files are copied, you need to create \code{metadata.mfs} file from changelogs and \code{metadata.back} files. To do this we need to use the command \code{mfsmaster -a}. \code{Mfsmaster} starts to build new metadata file and starts \code{mfsmaster} process.
\section{Maintenance mode}
Maintenance mode in general is helpful when there is need for maintenance on Chunkserver(s), like Chunkserver package upgrade to a newer version, adding new HDD / replacing broken ones or system upgrade (and e.g. reboot).
Maintenance mode has been introduced, because in MooseFS 1.6, when there was need for maintenance on Chunkserver(s) and necessity to turn server(s) off, a lot of replications were being performed, because MooseFS had started to replicate all undergoal chunks from another available copy to fulfill the goal (it's one of MooseFS principals). Then, when it was back again -- a lot of deletions were running, because of presence of overgoal chunks, created during replications. So a lot of unnecessary I/O operations.
By enabling maintenance mode before stopping Chunkserver(s) process(es) / turning machine(s) off or \textit{post factum}, you can prevent MooseFS from replicating chunks from such turned off Chunkserver(s). \textbf{Note: Server(s) in maintenance mode must match currently off (disconnected) servers. If they don't match, all chunks are replicated.}
Additionally, MooseFS treats Chunkservers in maintenance mode as overloaded (no chunk creations, replications etc.). It means, that new chunks are not created on Chunkservers in maintenance mode. The reason of such behavior is because when you want to turn Chunkserver off / stop the Chunkserver process, at the moment of stopping, some I/O operations may go to this Chunkserver and when you just stop it, some write operations must be re-tried (because they haven't been finished on this stopped Chunkserver). When you turn maintenance mode on for specific Chunkserver a few seconds before stop, MooseFS will finish write operations and won't start a new ones on this Chunkserver.
\textbf{Maintenance mode is designed to be a temporary state and it is not recommended to put Chunkservers in this mode for a long time.}
You can enable or disable maintenance mode in CGI monitor by clicking "switch on / switch off"
in "maintenance" column, or sending a command using:
\begin{itemize}
\item \code{mfscli -CM1/ip/port} -- to switch maintenance mode on
\item \code{mfscli -CM0/ip/port} -- to switch maintenance mode off
\end{itemize}
\bigskip
\textbf{Note: If number of Chunkservers in maintenance mode is equal or greater than 20\% of all Chunkserver, MooseFS treats all Chunkservers like maintenance mode wouldn't be enabled at all.}
\section{Chunk replication priorities}
In MooseFS 2.0 a few chunk replication classes and priorities have been introduced:
\begin{itemize}
\item Replication limit class 0 and class 1 -- replication for data safety
\item Replication limit class 2 and class 3 -- equalization of used disk space
\end{itemize}
\bigskip
\bigskip
These classes and priorities are described below:
\bigskip
\begin{itemize}
\item Replication limit class 0 (for endangered chunks):
\begin{itemize}
\item priority 0: 0 (chunk) copies on regular disks and 1 copy on disk marked for removal
\item priority 1: 1 copy on regular disks and 0 copies on disks marked for removal
\end{itemize}
\item Replication limit class 1 (for undergoal chunks):
\begin{itemize}
\item priority 2: 1 copy on regular disk and some copies on disks marked for removal
\item priority 3: $>$1 copy on regular disks and at least 1 copy on disks marked for removal
\item priority 4: just undergoal chunks ("goal" $>$ "valid copies", no copies on disks marked for removal)
\end{itemize}
\item Replication limit class 2: Rebalancing between chunkservers with disk space usage around arithmetic mean
\item Replication limit class 3: Rebalancing between chunkserver with disk space usage strongly above or strongly below arithmetic mean (very low or very high disk space usage, e.g. when new chunkserver is added)
\end{itemize}
\chapter{MooseFS Tools}
\section{For MooseFS Master Server(s)}
\subsection{\code{mfsmaster}}
\code{mfsmaster} -- start, restart or stop Moose File System master process
\bigskip
\textbf{SYNOPSIS}
\begin{itemize}
\item \code{mfsmaster [-c CFGFILE] [-u] [-i] [-a] [-e] [-x[x]] [-t LOCKTIMEOUT] [ACTION]}
\item \code{mfsmaster -v}
\item \code{mfsmaster -h}
\end{itemize}
\bigskip
\textbf{DESCRIPTION}
\code{mfsmaster} is the master program of Moose File System.
\bigskip
\textbf{OPTIONS}
\begin{itemize}
\item \code{-v} print version information and exit
\item \code{-h} print usage information and exit
\item \code{-c CFGFILE}
specify alternative path of configuration file (default is \code{mfsmaster.cfg} in system configuration directory)
\item \code{-u} log undefined configuration values (when default is assumed)
\item \code{-f} run in foreground, don't daemonize
\item \code{-t LOCKTIMEOUT}
how long to wait for lockfile (in seconds; default is 1800 seconds)
\item \code{-i} ignore some metadata structure errors
\item \code{-a} automatically restore metadata from change logs
\item \code{-e} start without metadata (usable only in pro version -- used to start additional masters)
\item \code{-x} produce more verbose output
\item \code{-xx} even more verbose output
\item \code{ACTION} is the one of \code{start}, \code{stop}, \code{restart}, \code{reload}, \code{test} or \code{kill}.
Default action is restart. The test action will yield one of two
responses: "\code{mfsmaster pid: PID}" or "\code{mfsmaster is not running}".
The kill action will send a SIGKILL to the currently running
master process. SIGHUP or reload action forces \code{mfsmaster} to
reload all configuration files.
\end{itemize}
\bigskip
\textbf{FILES}
\begin{itemize}
\item \code{mfsmaster.cfg}
configuration file for MooseFS master process; refer to
mfsmaster.cfg(5) manual for details
\item \code{mfsexports.cfg}
MooseFS access control file; refer to mfsexports.cfg(5) manual
for details
\item \code{mfstopology.cfg}
Network topology definitions; refer to mfstopology.cfg(5) manual
for details
\item \code{.mfsmaster.lock}
lock file of running MooseFS master process (created in data
directory)
\item \code{metadata.mfs}, \code{metadata.mfs.back}
MooseFS filesystem metadata image (created in data directory)
\item \code{changelog.*.mfs}
MooseFS filesystem metadata change logs (created in data
directory; merged into metadata.mfs once per hour)
\item \code{data.stats}