mfs常见问题翻译(moosefs)

Posted 2020-09-17

英文原文参见：

    https://moosefs.com/documentation/faq.html#26

找翻译工具翻译的，个人感觉还比较准确，如有疏漏和错误的地方，各位可留言说明。

欢迎交流沟通：QQ 249016681  

-------------------------------------------------------------------------------------

经常问的问题

 

目录：

1、我们期望什么平均的写入/读取速度？

2、目标设置是否影响写入/读取速度？

3、是否支持并发读写操作？

4、使用多少CPU / RAM资源？

5、是否可以在飞行中添加/删除chunkserver和磁盘？

6、如何标记要删除的磁盘？

7、我对集群文件系统的经验是元数据操作相当慢。你是如何解决这个问题的？

8、目录大小的值在MooseFS上有什么意义？它与标准Linux ls -l输出不同。为什么？

9、当我在文件系统上执行df -h时，结果与预期的相符，考虑到书面文件的实际大小。

10、我可以在MooseFS上保留源代码吗？为什么小文件占用的空间比预期的多？

11、Chunkservers和Metadata Server是否自行进行校验和？

12、主服务器需要什么资源？

13、当我删除文件或目录时，MooseFS大小不会改变。为什么？

14、当我添加第三台服务器作为额外的chunkserver，它看起来像系统开始将数据复制到第三台服务器，即使文件目标仍设置为2。

15、MooseFS 64位兼容吗？

16、我可以修改块大小吗？ 

17、如何知道文件是否已成功写入MooseFS

18、MooseFS有什么限制（例如文件大小限制，文件系统大小限制，最大文件数，可以存储在文件系统上）？

19、我可以为mfscgiserv设置HTTP基本身份验证吗？

20、我可以在MooseFS上运行邮件服务器应用程序吗？邮件服务器是一个非常繁忙的应用程序与大量的小文件 - 我不会丢失任何文件？

21、有没有对网络，MTU或带宽的建议？

22、MooseFS是否支持补充组？

23、MooseFS是否支持文件锁定？

24、可以通过DHCP为IP地址分配IP地址吗？

25、我的一些块服务器占用了90％的空间，而其他的只有10％。为什么重新平衡过程需要这么长时间？

26、我有Metalogger运行 - 我应该在主服务器上进一步备份元数据文件吗？

27、我认为我的一个磁盘较慢/损坏。我该怎么找到？

28、如何找到主服务器PID？

29、Web界面显示有一些具有目标0的块的副本。这是什么意思？

30、mfsmount报告的每个错误信息都是一个严重问题吗？

31、如何验证MooseFS集群是否联机？当主服务器关闭时，mfsmount会发生什么？

32、我们期望什么平均的写/读速度？

1.除了常见的（对于大多数文件系统）的因素，例如：块大小和访问类型（顺序或随机），MooseFS中的速度也取决于硬件性能。主要因素是硬盘性能和网络容量和拓扑（网络延迟）。使用的硬盘性能越好，网络的吞吐量越好，整个系统的性能越好。

2.目标设置是否影响写入/读取速度？

一般来说，没有。在读取文件的情况下，在某些情况下，高于一个目标的目标可能有助于加快读取操作，即当两个客户端访问目标为2或更高的文件时，它们可以对不同的副本执行读取操作，从而具有所有可用的通过自己的方式 但平均而言，目标设定不会以任何方式改变阅读操作的速度。

同样，写入速度也可以忽略不计地受到目标设定的影响。写入目标高于2的链接类似于：客户端将数据发送到一个组块服务器，并且组块服务器同时读取，写入数据并将数据发送到另一个组块服务器（这可能会将它们发送到下一个组件）实现目标）。这样一来，客户端的输入就不会发送多个副本，而且所有副本几乎同时被写入。我们的测试表明，写入操作可以在1Gbps网络中使用客户端的所有可用带宽。

3.是否支持并发读写操作？

所有读取操作是并行的 - 同一时刻几个客户端同时读取相同数据没有任何问题。写操作是并行的，execpt操作在相同的块（文件片段）上，由主服务器同步，因此需要是顺序的。

4.使用多少CPU / RAM资源？

在我们的环境中（共有1个PiB总空间，3600万个文件，100个机器上的3800万个数据包，600万个文件夹），使用chunkserver CPU（通过常量文件传输）约为15-30％，chunkserver RAM通常消耗在100Mb和1GiB之间（取决于每个块服务器上的块数量）。主服务器消耗现代3.3 GHz CPU的约50％（每秒大约5000个文件系统操作，其中大约1500个是修改）和12GiB RAM。CPU负载取决于操作数量和RAM对文件和文件夹的总数，而不是文件本身的总大小。RAM使用率与文件系统中的条目数成比例，因为主服务器进程将整个元数据保留在内存中以获得性能。我们主服务器上的HHD使用情况 22 GB。

5.是否可以在飞行中添加/删除chunkserver和磁盘？

您可以即时添加/删除大块服务器。但请记住，如果此服务器包含文件系统中的块的唯一副本，则断开连接服务器是不明智的（CGI监视器将标记为橙色）。您还可以断开（更改）单个硬盘驱动器。此操作的方案将是：

标记要删除的磁盘（请参阅如何标记磁盘以进行删除？）

重新加载chunkserver进程

等待复制（在CGI监视器中应该没有标记为黄色，橙色或红色的“经验”或“缺少”块）

停止chunkserver进程

删除mfshdd.cfg中断开的磁盘的条目

停止chunkserver机器

删除硬盘驱动器

启动机器

启动chunkserver进程

如果你有hotswap磁盘，你应该遵循这些：

标记要删除的磁盘（请参阅如何标记磁盘以进行删除？）

重新加载chunkserver进程

等待复制（在CGI监视器中应该没有标记为黄色，橙色或红色的“经验”或“缺少”块）

删除mfshdd.cfg中断开的磁盘的条目

重新加载chunkserver进程

卸载磁盘

删除硬盘驱动器

如果按照上述步骤，客户端计算机的工作不会中断，MooseFS用户将不会注意到整个操作。

6.如何标记磁盘以进行删除？

当您要标记要从chunkserver中删除的磁盘时，您需要编辑chunkserver的mfshdd.cfg配置文件，并在要删除的磁盘的行的开始处添加一个星号“ * ”。例如，在这个mfshdd.cfg中，我们标记了“ / mnt / hdd ”进行删除：

/ mnt / hda 

/ mnt / hdb 

/ mnt / hdc 

* / mnt / hdd 

/ mnt / hde

更改mfshdd.cfg后，您需要重新加载chunkserver（在Linux Debian / Ubuntu上：service moosefs-pro-chunkserver reload）。

一旦将磁盘标记为要删除并且重新启动了chunkserver进程，系统将会将存储在此磁盘上的块的相应份数拷贝，以维持所需的“目标”份数。

最后，在断开磁盘之前，您需要确认其他磁盘上没有“传统”块。这可以使用CGI监视器完成。在“信息”选项卡中选择“常规块状态矩阵”模式。

7.我对集群文件系统的经验是元数据操作相当慢。你是如何解决这个问题的？

在研究和开发过程中，我们还观察到元数据操作缓慢的问题。我们决定通过将文件系统结构保留在元数据服务器上的RAM中来缓解一些速度问题。这就是为什么元数据服务器增加了内存需求。元数据经常被刷新到主服务器上的文件。

另外，在CE版本中，元数据记录器服务器也经常接收到元数据结构的更新，并将它们写入其文件系统。

在Pro版本中，金属加工者是可选的，因为主要追随者与领导者主人保持同步。他们还将元数据保存到硬盘。

8.目录大小的值对MooseFS有什么意义？它与标准Linux ls -l输出不同。为什么？

文件夹大小在任何文件系统中都没有特别的意义，所以我们的开发团队决定给予额外的信息。该数字表示以指数表示法显示的所有文件的总长度（如mfsdirinfo -h -l）。

您可以通过以下方式“翻译”目录大小：

有7位数：xAAAABB。要将此符号转换为字节数，请使用以下表达式：

AAAA.BB xBytes

其中x：

0 =

1 =基比

2 = Mebi

3 =吉比

4 = Tebi

示例：

翻译以下条目：

drwxr-xr-x 164根根2010616 5月24日11:47测试

                         xAAAABB

文件夹大小2010616应该读为106.16 MiB。

当x = 0时，数字可能会更小：

示例：

文件夹大小10200表示102字节。

9.当我在文件系统上执行df -h时，结果与预期的相符，考虑到书面文件的实际大小。

每个chunkserver为每个使用的分区/ hdd发送自己的磁盘使用量增加256MB，并且主机将这些值的总和发送到客户端作为总磁盘使用量。如果您有3个chunkservers，每个7 hdd，您的磁盘使用量将增加3 * 7 * 256MB（约5GB）。

另一个区别的原因是，当您在chunkserver上使用专用于MooseFS的磁盘时，df将显示正确的磁盘使用情况，但如果您的MooseFS磁盘上有其他数据，df也会对您自己的文件进行计数。

如果要查看MooseFS文件的实际空间使用情况，请使用mfsdirinfo命令。

10.我可以在MooseFS上保留源代码吗？为什么小文件占用的空间比预期的多？

该系统最初设计用于保存大量（如几千个）非常大的文件（几十GB），并具有64MiB的硬编码块大小和64KiB的块大小。使用一致的块大小有助于提高网络性能和效率，因为系统中的所有节点都能够使用单个“桶”大小。这就是为什么即使一个小文件将占用64KiB加上另外4Ki的校验和和1KiB的标题。

关于存储在MooseFS块内的小文件的占用空间的问题真的更重要，但在我们看来，它仍然是微不足道的。让我们将2500万个文件的目标设置为2.计算存储开销，这可能会创建大约5000万69 KB的块，由于内部碎片（文件大小小于块大小），可能无法完全利用这些块。因此，5000万块的整体浪费空间约为3.2TiB。按照现代标准，这不应该是一个重大关切。由于使用的文件系统的块大小，更典型的中，大型项目，具有100,000个小文件将占用最多13GiB的额外空间。

所以在MooseFS系统上存储源代码文件是非常合理的，无论是在开发期间还是长期可靠的存储或存档目的下使用。

考虑到网络文件系统的性能，可能要考虑的较大因素是开发代码的舒适度。在主动开发项目下使用MooseFS（或任何其他基于网络的文件系统（如NFS，CIFS））时，网络文件系统可能无法以与直接连接的常规硬盘驱动器相同的速度执行文件IO操作。

一些现代集成开发环境（IDE）（如Eclipse）会在几个小型工作空间元数据文件上进行频繁的IO请求。使用MooseFS文件系统上的工作空间文件夹（以及任何其他联网文件系统）运行Eclipse将会比使用本地硬盘驱动器上的工作空间运行Eclipse时产生稍慢的用户界面性能。

如果您在IDE中使用MooseFS作为活动开发工作副本，则可能需要自己评估。

在另一个示例中，使用典型的文本编辑器进行源代码编辑和版本控制系统（如Subversion）将项目文件检入MooseFS文件系统，通常不会导致任何性能下降。MooseFS的网络文件系统性质的IO开销被与远程Subversion存储库交互的较大IO延迟所抵消。当使用简单的文本编辑器（复杂的IDE产品之外）时，单个文件操作（打开，保存）没有任何可观察到的延迟。

更有可能的情况是将Subversion存储库文件托管在MooseFS文件系统中，其中svnserver或Apache + mod_svn将向Subversion存储库提供请求，用户将检查工作沙箱到本地硬盘驱动器。

11. Chunkserver和Metadata Server是否会自己进行校验和？

块服务器做自己的校验和。每个64KiB块的开销约为4B，每个64MiB块为4KiB。

元数据服务器没有。我们以为这将占用CPU。我们建议使用ECC RAM模块。

12.主服务器需要哪些资源？

最重要的因素是MooseFS Master机器的RAM，因为完整的文件系统结构缓存在RAM中以提高速度。除了RAM之外，MooseFS Master机器需要HDD上的一些空间用于主元数据文件以及增量日志。

元数据文件的大小取决于文件数量（不是大小）。增量日志的大小取决于每小时的操作次数，但是此增量日志的长度（以小时计）可配置。

13.删除文件或目录时，MooseFS的大小不会改变。为什么？

MooseFS不会在删除时立即清除文件，以允许您还原删除操作。已删除的文件将保留在垃圾桶中，以便在删除之前配置的时间量。

您可以配置文件保存在垃圾箱的时间长度，并手动清空垃圾箱（以释放空间）。“参考指南”中有关详细信息，请参见“针对MooseFS的操作”一节。

简而言之，存储已删除文件的时间可以通过mfsgettrashtime命令进行验证，并使用mfssettrashtime进行更改。

14.当我添加第三台服务器作为额外的chunkserver时，即使文件目标仍设置为2，它看起来像是开始将数据复制到第三台服务器。

是。磁盘使用平衡器独立使用块，所以一个文件可以重新分配给所有的chunkserver。

15.MooseFS 64位兼容吗？

是!

16.我可以修改块大小吗？

否。文件数据分为最大64MiB的片段（块）。64 MiB的值被硬编码到系统中，因此您无法修改其大小。我们基于现实世界数据中的块大小，并确定它是块数之间和重新平衡/更新文件系统的速度之间的一个非常好的妥协。当然，如果文件小于64 MiB，它占用的空间就会更小。

在我们处理的系统中，几个文件大小显着超过100GB，没有明显的块大小的惩罚。

17.如何知道文件是否已成功写入MooseFS

我们简单讨论一下写入文件系统的过程以及这个程序的后果。

在所有当代文件系统中，文件通过缓冲区（写缓存）写入。因此，写入命令本身的执行只将数据传送到缓冲区（cache），而不会发生实际写入。因此，确认的写入命令的执行并不意味着数据已被正确写入盘。只有调用和完成fsync（或close）命令才能使保存在缓冲区（cache）内的所有数据都被物理地写出来。如果在写入这种缓冲区保存数据时发生错误，则可能导致fsync（或close）命令返回错误响应。

问题在于，绝大多数程序员不会测试关闭命令状态（这通常是一个非常常见的错误）。因此，向磁盘写入数据的程序可以“假设”数据已经从写入命令的成功响应中正确地写入，而实际上它可能在随后的关闭命令期间失败。

在网络文件系统（如MooseFS）中，由于其性质，缓冲区（缓存）中的“剩余”数据的平均数量将会高于常规文件系统。因此，在执行close或fsync命令期间处理的数据量通常很重要，并且如果在[从close或fsync命令]中写入数据时发生错误，则在执行此命令期间将返回为错误。因此，在执行关闭之前，建议（特别是在使用MooseFS时）在写入文件之后执行fsync操作，然后检查fsync操作结果的状态。那么，为了很好的衡量，还要检查关闭的返回状态。

注意！当使用stdio时，fflush功能只执行“write”命令，所以正确执行fflush不足以确保所有数据都已经写好 - 您还应该检查fclose的状态。

将程序的标准输出重定向到shell中的文件时，可能会出现上述问题。Bash（和许多其他程序）不检查关闭执行的状态。因此，“ application> outcome.txt ”类型的语法可能会在shell中成功结束，而实际上写出“ outcome.txt ”文件时出现错误。强烈建议您在写入MooseFS挂载点时避免使用上述shell输出重定向语法。如果需要，您可以创建一个简单的程序，读取标准输入并将所有内容写入所选文件，这个简单的程序将正确地使用fsync命令对结果状态的适当检查。例如，“ application | mysaver outcome.txt ”，

请注意，上述问题绝非例外，并不直接源于MooseFS本身的特征。它可能会影响任何文件系统 - 网络类型系统更容易出现这种困难。从技术上讲，上述建议应始终遵循（也适用于使用传统文件系统的情况）。

18. MooseFS有什么限制（例如文件大小限制，文件系统大小限制，最大文件数，可以存储在文件系统上）？

MooseFS中的最大文件大小限制为2 57字节= 128 PiB。

最大文件系统大小限制为2 64字节= 16 EiB = 16 384 PiB

可以存储在一个MooseFS实例上的最大文件数为2 31 - 超过2.1 bln。

19.我可以为mfscgiserv设置HTTP基本身份验证吗？

mfscgiserv是一个非常简单的HTTP服务器，仅用于运行MooseFS CGI脚本。它不支持任何其他功能，如HTTP身份验证。但是，MooseFS CGI脚本可以从具有CGI支持的另一个全功能HTTP服务器（如lighttpd或Apache）提供。当使用全功能的HTTP服务器（如Apache）时，您还可以利用其他模块提供的功能，例如HTTPS传输。只需将CGI及其数据文件（index.html，mfs.cgi，chart.cgi，mfs.css，acidtab.js，logomini.png，err.gif）放置在所选的DocumentRoot下。如果您在给定的主机上已经有一个HTTP服务器实例，

20.我可以在MooseFS上运行邮件服务器应用程序吗？邮件服务器是一个非常繁忙的应用程序与大量的小文件 - 我不会丢失任何文件？

您可以在MooseFS上运行邮件服务器。您不会在大系统负载下丢失任何文件。当文件系统忙时，它将阻塞，直到其操作完成，这将导致邮件服务器放慢速度。

21.有没有建议网络，MTU或带宽？

我们建议使用巨型帧（MTU = 9000）。使用更大量的块服务器，交换机应通过光纤连接或使用聚合链路。

22.MooseFS是否支持补充组织？

是。

23.MooseFS是否支持文件锁定？

是的，因为MooseFS 3.0。

24.可以通过DHCP将IP地址分配给块服务器吗？

是的，但我们强烈建议您根据MAC地址设置“DHCP预留”。

25.我的一些小块服务器占用了90％的空间，而其他的只有10％。为什么重新平衡过程需要这么长时间？

我们在生产环境中工作的经验表明，积极的复制是不可取的，因为它可以大大减缓整个系统。系统的整体性能比硬盘驱动器在所有组块服务器上的平等使用更为重要。默认情况下，复制被配置为非侵略性操作。在我们的环境下，新的chunkserver通常需要大约1个星期才能达到标准的hdd利用率。积极的复制将使整个系统在几天内相当缓慢。

可以通过设置以下两个选项在主服务器启动时调整复制速度：

CHUNKS_WRITE_REP_LIMIT

要复制到一个chunkserver的块的最大数量（默认值为2,1,1,4）。

一个数字等于以冒号分隔的四个相同的数字。

第一个限制是濒危块（只有一个副本的块）

第二个限制是对于传统的块（数量低于指定目标的块数）

第三个限制是针对具有算术平均值的空间使用的服务器之间的重新平衡

第四个限制是在其他服务器之间重新平衡（非常低或非常高的空间使用）

通常第一个数字应该大于或等于第二，第二大于或等于第三，第四大于或等于第三（1st> = 2nd> = 3rd <= 4th）。

CHUNKS_READ_REP_LIMIT

从一个chunkserver复制的块的最大数量（默认为10,5,2,5）。

一个数字等于以冒号分隔的四个相同的数字。限制组与写入限制相同，数字之间的关系应与写入限制相同（1st> = 2nd> = 3rd <= 4th）。

在您的环境中调整这些将需要一些实验。

26.我有一个Metalogger运行 - 我应该在主服务器上进一步备份元数据文件？

是的，强烈建议进一步备份元数据文件。如果由于某些原因，金属加工器数据不可用于恢复主服务器（例如，金属加工器服务器也被销毁），则这将提供最坏情况恢复选项。

主服务器将保存在RAM中的元数据每小时（xx：00）刷新到metadata.mfs.back二进制文件。因此，复制元数据文件的好时机是半小时（转储后30分钟）的每个小时。这会将数据丢失量限制在大约1.5h的数据。可以使用任何常规的复制元数据文件（cp，scp，rsync等）的方法来备份文件。

在基于此备份的元数据文件恢复系统后，最近创建的文件将丢失。此外，附加到的文件将具有它们之前的大小，它们在元数据备份时具有。被删除的文件将再次存在。而重命名或移动的文件将返回到之前的名称（和位置）。但是，在崩溃发生之前，仍然会有X在过去几年中创建的文件的所有数据。

在MooseFS Pro版本中，主要追随者从RAM一次一小时刷入元数据到硬盘。领导主人每天从追踪者中下载保存的元数据。

27.我认为我的一个磁盘较慢/损坏。我该怎么找到？

在CGI监视器中，进入“磁盘”选项卡，在“I / O统计”列中选择“切换到小时”，并在“最大时间”列中通过“写入”对结果进行排序。现在寻找一个显着更大的写入时间的磁盘。您还可以通过“fsync”列排序并查看结果。找到运行较慢的单个磁盘是个好主意，因为它们可能是系统的瓶颈。

创建一个测试操作可能是有帮助的，它连续复制一些数据，以便在系统上创建足够的负载，以便在CGI监视器中进行可观察的统计。在“磁盘”选项卡上，为“I / O统计”列指定单位“分钟”，而不是小时。

一旦找到了一个“坏”磁盘来替换它，就会遵循标记磁盘去除的常规操作，并等待颜色更改，以指示存储在此磁盘上的所有块都已被复制以实现足够的目标设置。

28.如何找到主服务器PID？

发出以下命令：

＃mfsmaster test

29.Web界面显示有一些目标为0的块的副本。这是什么意思？

这是一种标记属于不存在（即删除）文件的块的方法。在MooseFS中，异步删除文件。首先，文件从元数据中删除，其块被标记为不必要（目标= 0）。之后，在“闲置”时间内，这些块被删除。这比删除文件的确切时刻擦除所有内容要高得多。

如果主服务器在故障恢复之前创建，并且在还原的元数据文件中不可用，则也可能会在恢复主服务器之后出现不必要的块。

30. mfsmount报告的每个错误信息都是严重问题吗？

不，mfsmount将与chunkservers通信中遇到的每个故障写入syslog。网络中的瞬态通信问题可能会导致IO错误显示，但这并不意味着数据丢失，或者mfsmount将向应用程序返回错误代码。每个操作由客户机（mfsmount）重试几次，只有在故障次数（报告为尝试计数器）达到某个限制（通常为30）之后，该错误才会返回给应用程序，该数据未被读取/保存。

当然，监控这些消息很重要。当消息从一个chunkserver比其他消息更频繁地出现时，这可能意味着这个chunkserver有问题 - 也许硬盘坏了，也许网卡有一些问题 - 检查CGI中的图表，硬盘操作时间等监控。

注意：XXXXXXXX在下面的例子中是指chunkserver的IP地址。在mfsmount版本<2.0.42中chunkserver IP以十六进制格式写入。在mfsmount版本> = 2.0.42 IP是“人类可读”。

What does

file: NNN, index: NNN, chunk: NNN, version: NNN - writeworker: connection with (XXXXXXXX:PPPP) was timed out (unfinished writes: Y; try counter: Z)

message mean?

This means that Zth try to write the chunk was not successful and writing of Y blocks, sent to the chunkserver, was not confirmed. After reconnecting these blocks would be sent again for saving. The limit of trials is set by default to 30.

This message is for informational purposes and doesn‘t mean data loss.

What does

file: NNN, index: NNN, chunk: NNN, version: NNN, cs: XXXXXXXX:PPPP - readblock error (try counter: Z)

message mean?

This means that Zth try to read the chunk was not successful and system will try to read the block again. If value of Z equals 1 it is a transitory problem and you should not worry about it. The limit of trials is set by default to 30.

file: NNN, index: NNN, chunk: NNN, version: NNN - writeworker: connection with (XXXXXXXX:PPPP) was timed out (unfinished writes: Y; try counter: Z)

message mean?

This means that Zth try to write the chunk was not successful and writing of Y blocks, sent to the chunkserver, was not confirmed. After reconnecting these blocks would be sent again for saving. The limit of trials is set by default to 30.

This message is for informational purposes and doesn‘t mean data loss.

What does

file: NNN, index: NNN, chunk: NNN, version: NNN, cs: XXXXXXXX:PPPP - readblock error (try counter: Z)

message mean?

This means that Zth try to read the chunk was not successful and system will try to read the block again. If value of Z equals 1 it is a transitory problem and you should not worry about it. The limit of trials is set by default to 30. 

 

 

 

 

 

 

 

31.如何验证MooseFS群集是否在线？当主服务器关闭时，mfsmount会发生什么？

当主服务器在mfsmount已经运行时，mfsmount不会断开挂载的资源，并且等待保存的文件在尝试重新连接到主服务器时将保持很长时间。经过指定次数的尝试后，他们最终会返回EIO - “输入/输出错误”。另一方面，当主服务器脱机时，无法启动mfsmount。

有几种方法可以确保主服务器处于在线状态，下面列出其中的几个。

检查是否可以连接到主服务器的TCP端口（例如套接字连接测试）。

为了确保安装MooseFS资源，它足以检查inode编号 - MooseFS root将始终具有inode等于1.例如，如果我们在/ mnt / mfs中安装了MooseFS，那么stat / mnt / mfs命令（in Linux）将显示：

$ stat / mnt / mfs 

文件：`/ mnt / mfs‘ 

大小：xxxxxx块：xxx IO块：4096目录

设备：13h / 19d Inode：1链接：xx 

（...）

Additionaly mfsmount在根安装的文件夹中创建一个虚拟隐藏文件.stats。例如，获得的统计mfsmount时MooseFS安装我们的猫这个.stats文件，例如：

$ cat /mnt/mfs/.stats 

fuse_ops.statfs：241 

fuse_ops.access：0 

fuse_ops.lookup-cached：707553 

fuse_ops.lookup：603335 

fuse_ops.getattr-cached：24927 

fuse_ops.getattr：687750 

fuse_ops.setattr：24018 

fuse_ops。 mknod：0 

fuse_ops.unlink：23083 

fuse_ops.mkdir：4 

fuse_ops.rmdir：1 

fuse_ops.symlink：3 

fuse_ops.readlink：454 

fuse_ops.rename：269 

（...）

如果要确保主服务器正确响应，则需要尝试读取任何对象的目标，例如根文件夹：

$ mfsgetgoal / mnt / mfs 

/ mnt / mfs：2

如果您获得了根文件夹的正确目标，则可以确保主服务器已启动并正在运行。

本文出自 “Devops” 博客，请务必保留此出处http://devops9527.blog.51cto.com/2419132/1923079