轉自:http://hi.baidu.com/xuzhi1977/blog/item/c5869758dfafbade9d82040a.html
北亞數據恢復中心(http://www.datahf.net)張宇略作整理。
下面是原文：
以下文章是我自己翻譯的，後面有英文的原文。不當之處，敬請指教.
應該不是太新的文章，但是我我是2006-07-12的上午才看到的。哎........
2006-07-12 15:00 翻譯完成
--------------------------------------------------------------------------------------------------------------
腸子都悔青了，昨天剛剛新加的硬盤上面的文件系統還是被我搞成了ext3。如果我能造一天注意到這篇文章的話........
----------------------------------------------------------------------------------------------------------------
Debian Administration
System Administration Tips and Resources
現在還可以得到的許多Linux filesystems 比較，但是他們中大多數是古老的，基於為人任務的或者在更老的情況下完成。 這篇基准測試文基於與老一代的適合一台文件服務器的11項硬件(奔騰II/III，EIDE硬盤)。
從最初編制到出版，文章已經產生許多變化，意見和建議改進。我目前正努力進行一些新的試驗。(回答在原文范圍的問題)。
結果將在大約在(2006年5月8日)可提供
漢斯
為什麼要做基准測試？
我發現quantitative and reproductible benchmark基准使用2.6.x kernel。
Benoit在2003年在有512 MB RAM 的PIII 500服務器上使用大文件(1 + GB)實現12次試驗。 這次試驗信息十分豐富，但是結果對2.6.x kernel開始，主要適用於底座， 專門操作大的锉(例如，多媒體，科學，數據庫)。
Piszcz 在2006年實現21項任務(有768 MB RAM 和一個400GBEIDE-133硬盤在PIII-500 模擬多種文件操作)。到目前為止，這測試看起來是在2.6.x kernel上的最全面的工作。 但是， 很多任務是人造的(例如， 復制和刪除10，000個空目錄，新建10，000個文件，遞歸分割文件)，把這些結論應用到現實世界可能是無意義的。
因此， 這裡測試的基准的目標是驗證一些Piszcz(2006)的結論， 通過專門應用於現實世界在小型企業文件服務器(看見任務描述)裡找到。
測試基礎
* Hardware Processor : Intel Celeron 533
* RAM : 512MB RAM PC100
* Motherboard : ASUS P2B
* Hard drive : WD Caviar SE 160GB (EIDE 100, 7200 RPM, 8MB Cache)
* Controller : ATA/133 PCI (Silicon Image)
* OS Debian Etch (kernel 2.6.15), distribution upgraded . April 18, 2006
* All optional daemons killed (cron,ssh,saMBa,etc.)
* Filesystems Ext3 (e2fsprogs 1.38)
* ReiserFS (reiserfsprogs 1.3.6.19)
* JFS (jfsutils 1.1.8)
* XFS (xfsprogs 2.7.14)
選擇的測試任務描述
*在一個大文件(ISO 鏡像文件，700 MB)的從第2個磁盤復制到這個試驗磁盤
*再從在另一個位置再復制這個 ISO 一次
*刪除這個ISO 的兩個副本
*操作一文件樹(有7500 文件，900 目錄，1.9GB)，從第2 磁盤復制到這個試驗磁盤
*再從在另一個位置再復制這個文件樹 一次
*刪除這個文件樹的兩個副本
*用遞歸的方法遍歷文件樹目錄和文件樹的全部內容，復制到這個試驗磁盤
*匹配通配符，在文件樹查找具體的文件
*用(mkfs) 建立filesystem(全部FS都使用默認值)
*mount filesystem
*Umount filesystem
上述11項任務(從建立filesystem到umounting filesystem)的順序，編寫為Bash .運行完成3 次(報告平均成績)。 每個順序花費大約7分種，完成任務的時間用秒計算， GNU time utility (version 1.7) 記錄任務時的CPU 的利用百分比。
結果
分區能力
(在filesystem 創造之後)初始化分區並重新劃分block的過程裡，Ext3有最差的初始利用率(92.77%)， 其它的filesystem 幾乎可是使用全部的容量(ReiserFS = 99.83%，JFS = 99.82%，XFS = 99.95%)。
結論： 為了使用你的分區的的最大容量，選擇ReiserFS，JFS或者XFS。
建立文件系統，mount和unmounting
在20GB的分區創造filesystem測試，劃分為Ext3帶14.7秒， 與為相比其他filesystem多2秒或更少。(ReiserFS = 2.2，JFS = 1.3，XFS = 0.7)。
不過，掛載ReiserFS 要比其他的FS多花費5-15倍時間(2.3秒)(Ext3 = 0.2, JFS = 0.2, XFS = 0.5)，umount以及要比其他的FS多花費2 倍時間(0.4秒)。
所有的FS都花費差不多CPU占用來創建FS(59%（ReiserFS） -74%（JFS）)，掛載FS(在6和9%之間)。 不過，Ext3 和XFS多用2倍的CPU占用 給umount(37% 和45%)， ReiserFS和JFS(14% 和27%)。
結論： 對創建FS性能和mounting/unmounting來說，選擇JFS或者XFS。
大文件操作性能(ISO image，700 MB)
把大文件復制到Ext3(38.2秒)和ReiserFS(41.8)， 要比JFS和XFS(35.1和34.8)需要更多時間。使用XFS有助於提高在相同的磁盤上復制相同的文件(XFS=33.1,Ext3 = 37.3，JFS = 39.4，ReiserFS = 43.9)相比。 在JFS和XFS上刪除那些ISO 大約要快100 倍(0.02秒)，（ReiserFS1.5秒，Ext32.5秒）！所有FS復制時的CPU利用(在46和51%之間)，再復制時(在38%到50%之間)。當其他FS使用大約10%時，ReiserFS使用49%的CPU。 比他FS大約少5到10%)，JFS使用較少的CPU。
結論： 對大文件操作性能來說，最好選擇JFS或者XFS。 如果你需要使CPU利用減到最小，更推薦JFS。
目錄樹(7500個文件，900份目錄，1.9GB)的操作
最初復制目錄樹時，Ext3(158.3秒)和XFS(166.1秒)更迅速， ReiserFS和JFS(172.1和180.1)。在第二次復制的時候有相似的結果。（Ext3=120秒，XFS = 135.2，ReiserFS = 136.9 和JFS = 151)。但是， 移動目錄樹時Ext3(22秒)相比ReiserFS(8.2秒， XFS(10.5秒)和JFS(12.5秒))大約多2倍時間！所有FS在復制和再復制目錄樹時都使用較多的CPU (復制在27和36%之間)，(再復制在29%-JFS和45%-ReiserFS之間)。
令人吃驚，ReiserFS 和XFS使用更多的CPU 刪除目錄樹(86% 和65%)， 而其他FS只使用大約15%的(Ext3和JFS)。再次，與任何其他FS相比較，JFS的明顯使用較少CPU。 當有較多的數量較小頁面時適合ReiserFS。這個差別在目錄樹的再復制和移動裡的ReiserFS將有更高的速度。
結論：對在大容量的目錄樹操作來說，選擇Ext3或者XFS。 來自其他作者的基准測試已經證明如果使用ReiserFS，對大量的小文件更為合適。但是，目前包括各種各樣尺寸(10KB在5 MB)數千文件的目錄樹操作上，建議使用Ext3或者XFS可能獲得更好的性能。如果JFS的CPU占用減到最小，這種FS帶著相當高的性能。
目錄列表和文件查找
遞歸顯示目錄的目錄列表，ReiserFS(1.4秒)和XFS更迅速的1.8)， Ext3和JFS(2.5和3.1)。文件查找有著相同的結果。在文件查找項目， ReiserFS(0.8秒)相比XFS(2.8)和Ext3(4.6秒)和JFS(5秒)更迅速。 Ext3和JFS有更好CPU占用：目錄列表(35%)，文件查找(6%)。 XFS目錄列表(70%)使用更多的CPU，文件查找(10%)。 ReiserFS 看起來是占用CPU最多的FS，目錄列表71%，文件查找36% 。
結論： 結果表明那， 對於這些CPU占用任務來說，(ext3和JFS)filesystems 能更少的使用CPU的。 XFS作為好備選，帶有相對適中的性能和CPU的占用。
總的結論
這些結果從Piszcz(2006)關於分解的Ext3，ReiserFS的磁盤能力報告一樣。 這兩篇文章兩篇已經顯示JFS是最低的CPU利用的FS。 最後，這份報告看起來沒有顯示出ReiserFS的high page faults activity
由於一個分區只能有一個filesystem，認識每種filesystem的優缺點很重要。如果，以這篇文章的全部測試為基准， XFS看起來是家庭或者小型企業最適合的應用於文件服務器的filesystem：
*它使用你的服務器硬盤(s)的擁有最大的容量
*創建FS，mount和unmount很迅速
*操作大文件最迅速的FS(>500 MB)
*這FS得第二名地方給經營關於許多在適度尺寸文件和目錄小
*在CPU占用和目錄列表或者文件搜尋性能之間比較平衡，
*沒有最小CPU要求，老一代硬件也可十分接受
Piszcz(2006)當時沒有明確推薦XFS，他只是說："就個人來說，我仍然願意選擇同時具備性能和可伸縮性的XFS"。 現在我只能支持這個結論。
參考
貝努瓦，M.(2003)。 Linux 文件系統基准。
Piszcz，J.(2006)。 基准問題測試Filesystems第二部分。 Linux Gazette, 122 (January 2006)。
以下是原文
-----------------------------------------------------------------------
Debian Administration
System Administration Tips and Resources
[ About | Archive | FAQ | Hall of Fame | Search | Tagged Articles |
Filesystems (ext3, reiser, xfs, jfs) comparison . Debian Etch
There are a lot of Linux filesystems comparisons available but most of them are anecdotal, based . artificial tasks or completed under older kernels. This benchmark essay is based . 11 real-world tasks appropriate for a file server with older generation hardware (Pentium II/III, EIDE hard-drive).
Since its initial publication, this article has generated
a lot of questions, comments and suggestions to improve it.
Consequently, I'm currently working hard . a new batch of tests
to answer as many questions as possible (within the original scope
of the article).
Results will be available in about two weeks (May 8, 2006)
Many thanks for your interest and keep in touch with
Debian-Administration.org!
Hans
Why another benchmark test?
I found two quantitative and reproductible benchmark testing studies using the 2.6.x kernel (see References). Benoit (2003) implemented 12 tests using large files (1+ GB) . a Pentium II 500 server with 512MB RAM. This test was quite informative but results are beginning to aged (kernel 2.6.0) and mostly applied to settings which manipulate exclusively large files (e.g., multimedia, scientific, databases).
Piszcz (2006) implemented 21 tasks simulating a variety of file operations . a PIII-500 with 768MB RAM and a 400GB EIDE-133 hard disk. To date, this testing appears to be the most comprehensive work . the 2.6 kernel. However, since many tasks were "artificial" (e.g., copying and removing 10 000 empty directories, touching 10 000 files, splitting files recursively), it may be difficult to transfer some conclusions to real-world settings.
Thus, the objective of the present benchmark testing is to complete some Piszcz (2006) conclusions, by focusing exclusively . real-world operations found in small-business file servers (see Tasks de.ion).
Test settings
* Hardware Processor : Intel Celeron 533
* RAM : 512MB RAM PC100
* Motherboard : ASUS P2B
* Hard drive : WD Caviar SE 160GB (EIDE 100, 7200 RPM, 8MB Cache)
* Controller : ATA/133 PCI (Silicon Image)
* OS Debian Etch (kernel 2.6.15), distribution upgraded . April 18, 2006
* All optional daemons killed (cron,ssh,saMBa,etc.)
* Filesystems Ext3 (e2fsprogs 1.38)
* ReiserFS (reiserfsprogs 1.3.6.19)
* JFS (jfsutils 1.1.8)
* XFS (xfsprogs 2.7.14)
De.ion of selected tasks
* Operations . a large file (ISO image, 700MB) Copy ISO from a second disk to the test disk
* Recopy ISO in another location . the test disk
* Remove both copies of ISO
* Operations . a file tree (7500 files, 900 directories, 1.9GB) Copy file tree from a second disk to the test disk
* Recopy file tree in another location . the test disk
* Remove both copies of file tree
* Operations into the file tree List recursively all contents of the file tree and save it . the test disk
* Find files matching a specific wildcard into the file tree
* Operations . the file system Creation of the filesystem (mkfs) (all FS were created with default values)
* Mount filesystem
* Umount filesystem
The sequence of 11 tasks (from creation of FS to umounting FS) was run as a Bash . which was completed three times (the average is reported). Each sequence takes about 7 min. Time to complete task (in secs), percentage of CPU dedicated to task and number of major/minor page faults during task were computed by the GNU time utility (version 1.7).
RESULTS
Partition capacity
Initial (after filesystem creation) and residual (after removal of all files) partition capacity was computed as the ratio of number of available blocks by number of blocks . the partition. Ext3 has the worst inital capacity (92.77%), while others FS preserve almost full partition capacity (ReiserFS = 99.83%, JFS = 99.82%, XFS = 99.95%). Interestingly, the residual capacity of Ext3 and ReiserFS was identical to the initial, while JFS and XFS lost about 0.02% of their partition capacity, suggesting that these FS can dynamically grow but do not completely return to their inital state (and size) after file removal.
Conclusion : To use the maximum of your partition capacity, choose ReiserFS, JFS or XFS.
File system creation, mounting and unmounting
The creation of FS . the 20GB test partition took 14.7 secs for Ext3, compared to 2 secs or less for other FS (ReiserFS = 2.2, JFS = 1.3, XFS = 0.7). However, the ReiserFS took 5 to 15 times longer to mount the FS (2.3 secs) when compared to other FS (Ext3 = 0.2, JFS = 0.2, XFS = 0.5), and also 2 times longer to umount the FS (0.4 sec). All FS took comparable amounts of CPU to create FS (between 59% - ReiserFS and 74% - JFS) and to mount FS (between 6 and 9%). However, Ex3 and XFS took about 2 times more CPU to umount (37% and 45%), compared to ReiserFS and JFS (14% and 27%).
Conclusion : For quick FS creation and mounting/unmounting, choose JFS or XFS.
Operations . a large file (ISO image, 700MB)
The initial copy of the large file took longer . Ext3 (38.2 secs) and ReiserFS (41.8) when compared to JFS and XFS (35.1 and 34.8). The recopy . the same disk advantaged the XFS (33.1 secs), when compared to other FS (Ext3 = 37.3, JFS = 39.4, ReiserFS = 43.9). The ISO removal was about 100 times faster . JFS and XFS (0.02 sec for both), compared to 1.5 sec for ReiserFS and 2.5 sec for Ext3! All FS took comparable amounts of CPU to copy (between 46 and 51%) and to recopy ISO (between 38% to 50%). The ReiserFS used 49% of CPU to remove ISO, when other FS used about 10%. There was a clear trend of JFS to use less CPU than any other FS (about 5 to 10% less). The number of minor page faults was quite similar between FS (ranging from 600 - XFS to 661 - ReiserFS).
Conclusion : For quick operations . large files, choose JFS or XFS. If you need to minimize CPU usage, prefer JFS.
Operations . a file tree (7500 files, 900 directories, 1.9GB)
The initial copy of the tree was quicker for Ext3 (158.3 secs) and XFS (166.1) when compared to ReiserFS and JFS (172.1 and 180.1). Similar results were observed during the recopy . the same disk, which advantaged the Ext3 (120 secs) compared to other FS (XFS = 135.2, ReiserFS = 136.9 and JFS = 151). However, the tree removal was about 2 times longer for Ext3 (22 secs) when compared to ReiserFS (8.2 secs), XFS (10.5 secs) and JFS (12.5 secs)! All FS took comparable amounts of CPU to copy (between 27 and 36%) and to recopy the file tree (between 29% - JFS and 45% - ReiserFS). Surprisingly, the ReiserFS and the XFS used significantly more CPU to remove file tree (86% and 65%) when other FS used about 15% (Ext3 and JFS). Again, there was a clear trend of JFS to use less CPU than any other FS. The number of minor page faults was significantly higher for ReiserFS (total = 5843) when compared to other FS (1400 to 1490). This difference appears to come from a higher rate (5 to 20 times) of page faults for ReiserFS in recopy and removal of file tree.
Conclusion : For quick operations . large file tree, choose Ext3 or XFS. Benchmarks from other authors have supported the use of ReiserFS for operations . large number of small files. However, the present results . a tree comprising thousands of files of various size (10KB to 5MB) suggest than Ext3 or XFS may be more appropriate for real-world file server operations. Even if JFS minimize CPU usage, it should be noted that this FS comes with significantly higher latency for large file tree operations.
Directory listing and file search into the previous file tree
The complete (recursive) directory listing of the tree was quicker for ReiserFS (1.4 secs) and XFS (1.8) when compared to Ext3 and JFS (2.5 and 3.1). Similar results were observed during the file search, where ReiserFS (0.8 sec) and XFS (2.8) yielded quicker results compared to Ext3 (4.6 secs) and JFS (5 secs). Ext3 and JFS took comparable amounts of CPU for directory listing (35%) and file search (6%). XFS took more CPU for directory listing (70%) but comparable amount for file search (10%). ReiserFS appears to be the most CPU-intensive FS, with 71% for directory listing and 36% for file search. Again, the number of minor page faults was 3 times higher for ReiserFS (total = 1991) when compared to other FS (704 to 712).
Conclusion : Results suggest that, for these tasks, filesystems can be regrouped as (a) quick and more CPU-intensive (ReiserFS and XFS) or (b) slower but less CPU-intensive (ext3 and JFS). XFS appears as a good compromise, with relatively quick results, moderate usage of CPU and acceptable rate of page faults.
OVERALL CONCLUSION
These results replicate previous observations from Piszcz (2006) about reduced disk capacity of Ext3, longer mount time of ReiserFS and longer FS creation of Ext3. Moreover, like this report, both reviews have observed that JFS is the lowest CPU-usage FS. Finally, this report appeared to be the first to show the high page faults activity of ReiserFS . most usual file operations.
While recognizing the relative merits of each filesystem, .ly .e filesystem can be install for each partition/disk. Based . all testing done for this benchmark essay, XFS appears to be the most appropriate filesystem to install . a file server for home or small-business needs :
* It uses the maximum capacity of your server hard disk(s)
* It is the quickest FS to create, mount and unmount
* It is the quickest FS for operations . large files (>500MB)
* This FS gets a good second place for operations . a large number of small to moderate-size files and directories
* It constitutes a good CPU vs time compromise for large directory listing or file search
* It is not the least CPU demanding FS but its use of system ressources is quite acceptable for older generation hardware
While Piszcz (2006) did not explicitly recommand XFS, he concludes that "Personally, I still choose XFS for filesystem performance and scalability". I can .ly support this conclusion.
References
Benoit, M. (2003). Linux File System Benchmarks.
Piszcz, J. (2006). Benchmarking Filesystems Part II. Linux Gazette, 122 (January 2006).
Comment . this article
北亞RAID數據恢復中心張宇簡單整理：
文件系統 ext3 reiserfs jfs xfs
mkfs後利用率 92.77% 99.83% 99.82% 99.95%
mkfsr耗時 14.7秒 2.2秒 1.3秒 0.7秒
mount耗時 0.2秒 2.3秒 0.2秒 0.5秒
大文件操作 37.3秒 43.9秒 39.4秒 33.1秒
目錄樹操作 158.3秒 172.1秒 180.1秒 166.1秒
目錄列表和文件查找 2.5秒 1.4秒 2.5秒 1.8秒
