英文原文參見：
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
如果您獲得了根文件夾的正確目標，則可以確保主服務器已啓動並正在運行。