一、MFS介紹：
Distinctive features of MooseFS are:
MooseFS優越特性如下：
- higher reliability (data can be stored in several copies on separate computers)
高可用性（數據可以存儲在多個機器上的多個副本）
- dynamically expanding disk space by attaching new computers/disks
可動態擴展隨時新增加機器或者是磁盤
- possibility of storing deleted files for a defined period of time ("trash
bin" service on a file system level)
可回收在指定時間內刪除的文件（“垃圾回收站”是一個系統級別的服務）
- possibility of creating snapshot of a file, which means coherent copy of the
whole file, even while the file is being written.
可以對整個文件甚至在正在寫入的文件創建文件的快照。
System Architecture：
系統架構如下：
MFS文件系統結構: 包含4種角色:
管理服務器managing server (master) ：負責各個數據存儲服務器的管理，文件讀寫調度，文件空間回收以及恢復.多節點拷貝。
single computer managing the whole filesystem,storing metadata for every file (information on size, attributes and file localisation(s), including all information about non-regular files, i.e.directories, sockets, pipes and devices).
單個機器管理整個文件系統，用來存儲記錄每一個文件的Metadata（記錄文件的大小、文件的屬性、文件的位置，也包括非規則文件的系統，如目錄、sockets、管道和設備）
元數據日誌服務器Metalogger server（Metalogger）：負責備份master服務器的變化日誌文件，文件類型爲changelog_ml.*.mfs，以便於在master server出問題的時候接替其進行工作。
數據存儲服務器data servers (chunkservers) ：負責連接管理服務器,聽從管理服務器調度，提供存儲空間，併爲客戶提供數據傳輸。
客戶機掛載使用client computers ：通過fuse內核接口掛接遠程管理服務器上所管理的數據存儲服務器,.看起來共享的文件系統和本地unix文件系統使用一樣的效果。
二、mfs各元素主要配置文件
1、master
主服務器
Metadata is stored in memory of the managing server and simultaneously is being saved on disk (as a periodically updated binary file and immediately updated incremental logs). The main binary file as well as the logs are replicated to metaloggers (if present).
Metadata元數據存儲在master服務器的內存中，同時也保存在磁盤上（作爲一個定期更新的二進制文件，並實時的更新changelog日誌）。如果存在metaloggers的話，主要的二進制文件以及日誌也複製到metaloggers中。
How much CPU/RAM resources are used?
消耗多少CPU和內存資源
In our environment (ca. 500 TiB, 25 million files, 2 million folders distributed on 26 million chunks on 70 machines) the usage of chunkserver CPU (by constant file transfer) is about 15-20% and chunkserver RAM usually consumes about 100MiB (independent of amount of data).
在我們的測試環境中（大約500 TiB的數據，250萬份文件，200萬文件夾，分成260萬塊分佈在70機器上），chunkserver的CPU使用情況爲（持續的文件傳輸）約爲15-20％同時chunkserver內存使用100MiB（和數據量的多少無關）。
The master server consumes about 30% of CPU (ca. 1500 operations per second) and 8GiB RAM. CPU load depends on amount of operations and RAM on number of files and folders.
master服務器消耗約30％的CPU（每秒鐘約1500次操作）和8G的內存。 CPU負載取決於操作的次數，內存的使用取決於文件和文件夾的個數。
File data is divided to fragments (chunks) of maximum size 64MB each which are stored as files on selected disks on data servers (chunkservers). Each chunk is saved on different computers in a number of copies equal to a "goal" for the given file.
文件數據是按塊爲單位（塊的最大大小64MB以上）存儲在數據服務器（chunkservers）上指定磁盤上。如果設置的goal的存儲分數和機器個數相同，不同的塊兒會存儲在每一個機器上。
What sort of sizing is required for the Master server?
對Master主服務器有什麼需求？
The most important factor is RAM of mfsmaster machine, as the full file system structure is cached in RAM for speed. Besides RAM mfsmaster machine needs some space on HDD for main metadata file together with incremental logs.
最重要的因素就是mfsmaster機器的內存，因爲整個文件系統結構都緩存到內存中以便加快訪問速度。除了內存mfsmaster機器還需要一定硬盤大小用來存儲Metadata數據和增長的日誌文件。
The size of the metadata file is dependent on the number of files (not on their sizes). The size of incremental logs depends on the number of operations per hour, but length (in hours) of this incremental log is configurable.
Metadata文件的大小是取決於文件數的多少（而不是他們的大小）。changelog日誌的大小是取決於每小時操作的數目，但是這個時間長度（默認是按小時）是可配置的。
1 million files takes approximately 300 MiB of RAM. Installation of 25 million files requires about 8GiB of RAM and 25GiB space on HDD.
100萬文件大約需要300M內存。25百萬份文件大約需要8GiB內存和25GiB硬盤空間。
master主要文件
mfsmaster.cfg
configuration file for MooseFS master process
參數說明如下：
#WORKING_USER和WORKING_GROUP：是運行master server的用戶和組；
#SYSLOG_IDENT：是master server在syslog中的標識，也就是說明這是由master server產生的；
#LOCK_MEMORY：是否執行mlockall()以避免mfsmaster 進程溢出（默認爲0，即否）；
#NICE_LEVE：運行的優先級(如果可以默認是 -19; 注意: 進程必須是用root啓動)；
#EXPORTS_FILENAME：被掛接目錄及其權限控制文件的存放位置
#DATA_PATH：metadata files and lock file存放路徑，此目錄下大致有以下文件：metadata，changelog，sessions，stats，lock。
#BACK_LOGS：metadata的change log文件數目(默認是 50);
#REPLICATIONS_DELAY_INIT：(initial delay in seconds before starting replications)初始延遲複製的時間（默認是300s）;
#REPLICATIONS_DELAY_DISCONNECT：(replication delay in seconds after chunkserver disconnection） chunkserver斷開後複製延遲（默認是3600s）；
# MATOML_LISTEN_HOST：用於metalogger連接的IP地址(默認是*，代表任何IP)；
# MATOML_LISTEN_PORT：監聽metalogger請求的端口地址(默認是9419)；
# MATOCS_LISTEN_HOST：用於chunkserver連接的IP地址（默認是*，代表任何IP）；
# MATOCS_LISTEN_PORT：監聽chunkserver連接的端口地址（默認是9420）；
# MATOCU_LISTEN_HOST：用於客戶端掛接連接的IP地址(默認是*，代表任何IP)；
# MATOCU_LISTEN_PORT：監聽客戶端掛載連接的端口地址（默認是9421）；
# CHUNKS_LOOP_TIME ：（Chunks loop frequency in seconds）chunks的迴環頻率（默認是：300秒）；
# CHUNKS_DEL_LIMIT：（Maximum number of chunks to delete in one loop）在一個loop中可以刪除chunks的最大數 (默認：100)
# CHUNKS_WRITE_REP_LIMIT：（Maximum number of chunks to replicate to one chunkserver in one loop）在一個loop裏複製到一個chunkserver的最大chunk數目（默認是1）
# CHUNKS_READ_REP_LIMIT：（Maximum number of chunks to replicate from one chunkserver in one loop）在一個loop裏從一個chunkserver複製的最大chunk數目（默認是5）
# REJECT_OLD_CLIENTS：彈出低於1.6.0的客戶端掛接（0或1，默認是0）
mfsexports.cfg
MooseFS access control file
地址可以指定的幾種表現形式：所有ip，單個ip，IP網絡地址/位數掩碼，IP網絡地址/子網掩碼，ip段範圍。
權限部分：
ro 只讀模式共享
rw 讀寫方式共享
alldirs 許掛載任何指定的子目錄
maproot 映射爲root，還是指定的用戶
password 指定客戶端密碼
.mfsmaster.lock
lock file of running MooseFS master process
mfsmaster.lock文件記錄正在運行的MooseFS 的主進程
metadata.mfs, metadata.mfs.back
MooseFS filesystem metadata image
metadata.mfs, metadata.mfs.back是MooseFS文件系統的元數據metadata的鏡像
changelog.*.mfs
MooseFS filesystem metadata change logs (merged into metadata.mfs once per hour)
changelog.*.mfs 是MooseFS文件系統元數據的改變日誌（每一個小時合併到metadata.mfs中一次）
The size of the metadata file is dependent on the number of files (not on their sizes). The size of incremental logs depends on the number of operations per hour。
Metadata文件的大小取決於文件數（而不是他們的大小），Changelog的大小取決於每小時的操作次數。
2、metalogger
主要文件：
mfsmetalogger.cfg
# WORKING_USER = mfs
# WORKING_GROUP = mfs
# SYSLOG_IDENT = mfsmetalogger
# LOCK_MEMORY = 0
# NICE_LEVEL = -19
# DATA_PATH = /usr/local/mfs/var/mfs
# BACK_LOGS = 50
META_DOWNLOAD_FREQ = 1 # metadata download frequency in hours (default is 24, at most BACK_LOGS/2) 。metadata元數據下載間隔時間（默認是24小時，單位是小時，至多是BACK_LOGS的1/2）
# MASTER_RECONNECTION_DELAY = 5 # delay in seconds before trying to reconnect to master after disconnection。在失去連接之後延遲多少秒重新連接master
MASTER_HOST = 192.168.5.230
# MASTER_PORT = 9419
# MASTER_TIMEOUT = 60 # timeout (in seconds) for master connections。Master連接超時時間（單位是秒）
# deprecated, to be removed in MooseFS 1.7
# LOCK_FILE = /var/run/mfs/mfsmetalogger.lock
.mfsmetalogger.lock
changelog_ml.*.mfs
MooseFS filesystem metadata change logs (backup of master change log files)
changelog_ml.*.mfs是MooseFS文件系統的元數據的changelog日誌（備份的Master 的Master的changelog日誌。）
metadata.ml.mfs.back
Latest copy of complete metadata.mfs.back file from MooseFS master.
metadata.ml.mfs.back是從Master主機上下載的最新的完整metadata.mfs.back的拷貝
sessions.ml.mfs
Latest copy of sessions.mfs file from MooseFS master.
sessions.ml.mfs是從master下載的最新的sessions.mfs文件拷貝。
3、chunker
主要文件：
mfschunkserver.cfg
# WORKING_USER = mfs
# WORKING_GROUP = mfs
# SYSLOG_IDENT = mfschunkserver
# LOCK_MEMORY = 0
# NICE_LEVEL = -19
# DATA_PATH = /usr/local/mfs/var/mfs
# MASTER_RECONNECTION_DELAY = 5 （delay in seconds before trying to reconnect to master after disconnection）在失去連接之後延遲多少秒重新連接master
MASTER_HOST = 192.168.5.230 元數據服務器的名稱或地址，可以是主機名，也可以是ip地址。只要數據存儲服務器能訪問到元數據服務器就行。
# MASTER_PORT = 9420
# MASTER_TIMEOUT = 60
# CSSERV_LISTEN_HOST = * #IP address to listen on for client (mount) connections (* means any) 允許掛載的客戶端連接的IP地址（*允許全部）
# CSSERV_LISTEN_PORT = 9422
# CSSERV_TIMEOUT = 5 #timeout (in seconds) for client (mount) connections
客戶端掛載連接的超時時間（單位爲秒）
# HDD_CONF_FILENAME = /usr/local/mfs/etc/mfshdd.cfg #分配給MFS使用的磁盤空間配置文件的位置
# HDD_TEST_FREQ = 10 #chunk test period in seconds 塊的測試期（單位爲秒）
# deprecated, to be removed in MooseFS 1.7
# LOCK_FILE = /var/run/mfs/mfschunkserver.lock
# BACK_LOGS = 50
mfshdd.cfg
list of directories (mountpoints) used for MooseFS storage (one per line; directory prefixed by *
character causes given directory to be freed by replicating all data already stored there to another
locations) Lines starting with # character are ignored as comments。
mfschunkserver.lock
lock file of running MooseFS chunkserver process
4、mfsmount
三、MFS讀寫性能：
簡單測試結果：
寫：time dd if=/dev/zero of=/usr/mfstest/test2/zhhtest500M bs=1024k count=500
讀：time dd if=/usr/mfstest/test2/zhhtest500M of=/dev/null
|
|
1copy寫 |
2copy寫 |
1copy讀 |
2copy讀 |
|
1M |
0m0.042s |
0m0.042s |
0m0.017s |
0m0.017s |
|
2M |
0m0.056s |
0m0.066s |
0m0.030s |
0m0.055s |
|
5M |
0m0.073s |
0m0.079s |
0m0.070s |
0m0.071s |
|
10M |
0m0.119s |
0m0.131s |
0m0.136s |
0m0.197s |
|
20M |
0m0.250s |
0m0.288s |
0m0.291s |
0m0.376s |
|
50M |
0m0.514s |
0m0.589s |
0m0.896s |
0m0.886s |
|
100M |
0m0.977s |
0m7.497s |
0m1.677s |
0m1.787s |
|
200M |
0m7.910s |
0m22.270s |
0m2.683s |
0m3.129s |
|
500M |
0m22.465s |
0m51.735s |
0m6.559s |
0m6.990s |
|
1G |
0m52.346s |
1m48.056s |
0m17.319s |
0m17.154s |
|
2G |
1m46.224s |
3m46.283s |
0m41.608s |
0m34.435s |
|
5G |
4m41.956s |
9m34.798s |
2m9.200s |
1m56.183s |
|
10G |
9m29.037s |
19m26.237s |
3m55.222s |
3m24.914s |
|
100G |
95m53.500s |
195m7.173s |
32m4.295s |
41m26.995s |
總結規律：
1、讀速度：ca 71M/s 寫速度：ca 22M/s 9M/s （以500M計算）
2、goal的設置和讀寫速度的關係？貌似沒有關係。
What average write/read speeds can we expect?
理想的平均寫和讀的速度是多少？
The raw reading / writing speed obviously depends mainly on the performance of the used hard disk drives and the network capacity and its topology and varies from installation to installation. The better performance of hard drives used and better throughput of the net, the higher performance of the whole system.
原始的讀/寫速度很明顯是主要取決於所使用的硬盤的性能、網絡的容量和拓撲結構的，使用的硬盤和網絡的吞吐量越好，整個系統的性能也就會越好。
In our in-house commodity servers (which additionally make lots of extra calculations) and simple gigabyte Ethernet network on a petabyte-class installation on Linux (Debian) with goal=2 we have write speeds of about 20-30 MiB/s and reads of 30-50MiB/s. For smaller blocks the write speed decreases, but reading is not much affected.
在我們的測試環境中，將MFS安裝在linux（Debian）上設置存儲的份數爲2，一般的測試服務器（還做了其他較大量的計算），G太網絡，使用Pbyte級別的數據，測試的結果爲寫的速度大約在20-30MB/s，讀的速度爲30-50MB/s。對於小文件寫的速度有些下降，但是對於讀的速度是沒有影響的。
Does the goal setting influence writing/reading speeds?
設置文件存儲的份數是否影響寫/讀的速度？
Generally speaking, it doesn’t. The goal setting can influence the reading speed only under certain conditions. For example, reading the same file at the same time by more than one client would be faster when the file has goal set to 2 and not goal=1.
一般來說，它是有影響的。在一定條件下，存儲份數的設置會影響的讀取的速度。例如，當文件設置存儲兩份而不是一份時能加快對同一文件有多個客戶端讀取的速度。
But the situation in the real world when several computers read the same file at the same moment is very rare; therefore, the goal setting has rather little influence on the reading speeds.
但是在真實的環境中，多個機器同時讀取同一個文件的機率是比較小的，因此，存儲分數的設置對讀取的速度影響是比較小的。
Similarly, the writing speed is not much affected by the goal setting.（if only the file is bigger than 64MiB）
同樣，設置存儲份數對寫的速度影響也是不太大的。(只有文件超過64M的時候)
四、災難測試、恢復及其他測試
1、client 機器無論怎樣操作都不會影響master。
客戶端強制kill -9殺掉mfsmount進程，需要先umount，然後再mount。否則會提示：
fuse: bad mount point `/usr/mfstest/': Transport endpoint is not connected
see: /usr/local/mfs/bin/mfsmount -h for help
2、matser、metalogger、chunker、client端，服務器關機（init0）和重啓（init6）時，程序都是正常關閉，無需修復。
3、master啓動後，metalogger、chunker、client三個元素都能自動與master建立連接。
正常啓動順序：matser---chunker---metalogger---client
關閉順序：client---chunker---metalogger---master
但實際中無論如何順序啓動或關閉，未見任何異常。
4、整個mfs體系中，直接斷電只有master有可能無法啓動。
使用mfsmetarestore -a修復才能啓動，如果無法修復，使用metalogger上的備份日誌進行恢復。（幾次測試發現：如果mfsmetarestore -a無法修復，則使用metalogger也無法修復）。
強制使用metadata.mfs.back創建metadata.mfs，可以啓動master，但丟失的數據暫無法確定（此問題已經請教MFS開發小組）。
直接斷電測試過程，使用mfsmetarestore –a無法修復，使用metalogger也無法修復的情況較少發生。5次只有一次無法修復。
5、chunker的維持：chunker的塊（chunks）能夠自動複製或刪除
對一個目錄設定“goal”，此目錄下的新創建文件和子目錄均會繼承此目錄的設定，但不會改變已經存在的文件及目錄的copy份數。但使用-r選項可以更改已經存在的copy份數。
goal設置爲2，只要兩個chunker有一個能夠正常運行，數據就能保證完整性。
假如每個文件的goal（保存份數）都不小於2，並且沒有under-goal文件（可以用mfsgetgoal –r和mfsdirinfo命令來檢查），那麼一個單一的chunkserver在任何時刻都可能做停止或者是重新啓動。以後每當需要做停止或者是重新啓動另一個chunkserver的時候，要確定之前的chunkserver被連接，而且要沒有under-goal chunks。
實際測試時，傳輸一個大文件，設置存儲2份。傳輸過程中，關掉chunker1，這樣絕對會出現有部分塊只存在chunker2上；啓動chunker1，關閉chuner2，這樣絕對會有部分塊只存在chuner1上。
把chunker2啓動起來。整個過程中，客戶端一直能夠正常傳輸。
在客戶端查看，一段時間內，無法查看；稍後一段時間後，就可以訪問了。文件正常，使用mfsfileinfo 查看此文件，發現有的塊分佈在chunker1上，有的塊分佈在chuner2上。
使用mfssetgoal 2和mfssetgoal -r 2均不能改變此文件的目前塊的現狀。
但使用mfssetgoal -r 1後，所有塊都修改成1塊了，再mfssetgoal -r 2，所有塊都修改成2份了。
測試chunker端，直接斷電情況下，chunker會不會出問題：
a、數據傳輸過程中，關掉chunker1，等待數據傳輸完畢後，開機啓動chunker1.
chunker1啓動後，會自動從chunker2複製數據塊。整個過程中文件訪問不受影響。
b、數據傳輸過程中，關掉chunker1，不等待數據傳輸完畢，開機啓動chunker1.
chunker1啓動後，client端會向chunker1傳輸數據，同時chunker1也從chunker2複製缺失的塊。
如果有三臺chunker，設置goal=2，則隨機挑選2個chunker存儲。
如果有一個chunker不能提供服務，則剩餘的2個chunker上肯定有部分chunks保存的是一份。則在參數（REPLICATIONS_DELAY_DISCONNECT = 3600）後，只有一份的chunks會自動複製一份，即保存兩份。
保存兩份後，如果此時壞掉的chunker能夠提供服務後，此時肯定有部分chunks存儲了三份，mfs會自動刪除一份。
6、chunks修復 ：mfsfilerepair
mfsfilerepair deals with broken files (those which cause I/O errors on read operations) to make them partially readable. In case of missing chunk it fills missing parts of file with zeros; in case of chunk version mismatch it sets chunk version known to mfsmaster to highest one found on chunkservers. Note: because in the second case content mismatch can occur in chunks with the same version, it’s advised to make a copy (not a snapshot!) and delete original file after "repairing".
Mfsfilerepair主要是處理壞文件的（如寫操作引起的I/O錯誤）使文件能夠部分可讀。作用如下：在丟失塊的情況下使用0對丟失文件進行填充；在塊的版本號不匹配時設置快的版本號爲master上已知的能在chunkerservers找到的最高版本號；注意：因爲在第二種情況的內容不匹配，可能發生在塊具有相同的版本，建議進行文件的拷貝（而不是進行不快照！），並刪除原始文件再進行文件的修復。
Client端大文件傳輸過程中，強制拔下master主機電源，造成master非法關閉，使用mfsmetarestore -a修復後，master日誌報告有壞塊：
Jan 19 17:22:17 ngmaster mfsmaster[3250]: chunkserver has nonexistent chunk (000000000002139F_00000001), so create it for future deletion
Jan 19 17:22:18 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F creation status: 20
Jan 19 17:25:18 ngmaster mfsmaster[3250]: chunk 000000000002139F has only invalid copies (1) - please repair it manually
Jan 19 17:25:18 ngmaster mfsmaster[3250]: chunk 000000000002139F_00000001 - invalid copy on (192.168.5.232 - ver:00000000)
Jan 19 17:26:43 ngmaster mfsmaster[3250]: currently unavailable chunk 000000000002139F (inode: 135845 ; index: 23)
Jan 19 17:26:43 ngmaster mfsmaster[3250]: * currently unavailable file 135845: blog.xxx.cn-access_log200904.tar.gz
Client端使用mfsfilerepair修復
[root@localhost mfstest]# /usr/local/mfs/bin/mfsfilerepair blog.xxx.cn-access_log200904.tar.gz
blog.xxt.cn-access_log200904.tar.gz:
chunks not changed: 23
chunks erased: 1
chunks repaired: 0
查看master日誌，發現：
Jan 19 17:30:17 ngmaster mfsmaster[3250]: chunk hasn't been deleted since previous loop - retry
Jan 19 17:30:17 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F deletion status: 13
Jan 19 17:35:16 ngmaster mfsmaster[3250]: chunk hasn't been deleted since previous loop - retry
Jan 19 17:35:16 ngmaster mfsmaster[3250]: (192.168.5.232:9422) chunk: 000000000002139F deletion status: 13
Client端執行以下操作後，master不再報告相關信息：
mv blog.xxt.cn-access_log200904.tar.gz blog.xxt.cn-access_log200905.tar.gz
7、chunker的空間
每一個chunkserver的磁盤都要爲增長中的chunks保留些磁盤空間，從而達到創建新的chunk。只有磁盤都超過256M並且chunkservers報告自由空間超過1GB總量纔可以被新的數據訪問。最小的配置,應該從幾個G 字節的存儲。
When doing df -h on a filesystem the results are different from what I would expect taking into account actual sizes of written files.
在文件系統上做df –h得到的結果和我已經寫進去的文件大小不一致？
Every chunkserver sends its own disk usage increased by 256MB for each used partition/hdd, and a sum of these master sends to the client as total disk usage. If you have 3 chunkservers with 7 hdd each, your disk usage will be increased by 3*7*256MB (about 5GB). Of course it's not important in real life, when you have for example 150TB of hdd space.
每個chunkerserver每次以256M的磁盤空間進行申請，而發給客戶端的是這個空間加起來的總和。例如：如果你有3個chunkerserver7個分區磁盤，每次你的硬盤使用會增加3*7*256MB (大約5GB)。當然如果在現實生活中你的硬盤大小爲150T的大小，這是對你來說是不重要的。
There is one other thing. If you use disks exclusively for MooseFS on chunkservers df will show correct disk usage, but if you have other data on your MooseFS disks df will count your own files too.
另外，如果你的chunkservers使用專用的磁盤，df將顯示正確的磁盤使用情況。但是如果你有其他的數據在你的MooseFS磁盤上，df將會計算你所有的文件。
If you want to see usage of your MooseFS files use 'mfsdirinfo' command.
如果你想看你的MooseFS文件的使用情況，請使用'mfsdirinfo'命令。
8、快照snapshot
可以快照任何一個文件或目錄，語法：mfsmakesnapshot src dst
但是src和dst必須都屬於mfs體系，即不能mfs體系中的文件快照到其他文件系統。both elements must be on the same device。
元素必須是相同的設備上。
Mfsappendchunks：追加chunks到一個文件
append file chunks to another file. If destination file doesn't exist then it's created as empty file and then chunks are appended
追加文件塊到另一個文件。如果目標文件不存在，則會創建一個空文件，然後繼續將塊進行追加。
9、回收站 trash bin
設置文件或目錄的刪除時間。一個刪除的文件能夠存放在“ 垃圾箱”中的時間稱爲隔離時間， 這個時間可以用mfsgettrashtime 命令來查看，用mfssettrashtime 命令來設置。單位爲秒。
單獨安裝或掛載MFSMETA 文件系統，它包含目錄/ trash (包含仍然可以被還原的刪除文件的信息)和/ trash/undel (用於獲取文件)。
把刪除的文件，移到/ trash/undel下，就可以恢復此文件。
在MFSMETA 的目錄裏，除了trash 和trash/undel 兩個目錄，還有第三個目錄reserved，該目錄內有已經刪除的文件，但卻被其他用戶一直打開着。在用戶關閉了這些被打開的文件後，reserved 目錄中的文件將被刪除，文件的數據也將被立即刪除。此目錄不能進行操作。
10、文件描述符
1.5.12版本，進行大量小文件寫時，出現了一個嚴重錯誤，有可能和操作系統文件描述符有關。操作系統默認文件描述符爲1024.
1.6.11版本默認爲100000
建議上線時，master和chunker修改文件描述符，即修改/etc/security/limits.conf添加
* - nofile 65535
以上測試有劉運鋒、鄭輝共同完成。
五、監控與報警
