Linux各種文件系統(ext3,ReiserFS,jfs,xfs)的性能
2006-07-28 08:55
以下文章是我自己翻譯的，后面有英文的原文。不當之處，敬請指教.
應該不是太新的文章，但是我我是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 on 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 script運行完成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 on Debian Etch
There are a lot of Linux
filesystems comparisons available but most of them are anecdotal, based on
artificial tasks or completed under older kernels. This benchmark essay is based
on 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 on 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) on 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 on a PIII-500 with 768MB RAM and a 400GB
EIDE-133 hard disk. To date, this testing appears to be the most comprehensive
work on 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 on
real-world operations found in small-business file servers (see Tasks
description).
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 on 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)
Description of selected
tasks
* Operations on a large file (ISO image, 700MB) Copy ISO from a
second disk to the test disk
* Recopy ISO in another location on the test
disk
* Remove both copies of ISO
* Operations on 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 on 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 on the test
disk
* Find files matching a specific wildcard into the file tree
* Operations on 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 script 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 on 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 on 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 on a large file (ISO image, 700MB)
The initial
copy of the large file took longer on Ext3 (38.2 secs) and ReiserFS (41.8) when
compared to JFS and XFS (35.1 and 34.8). The recopy on 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 on 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 on large files, choose JFS or XFS. If you need to minimize CPU usage,
prefer JFS.
Operations on 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 on 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 on large file tree, choose Ext3 or XFS. Benchmarks from other
authors have supported the use of ReiserFS for operations on large number of
small files. However, the present results on 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 on most usual
file operations.
While recognizing the relative merits of each
filesystem, only one filesystem can be install for each partition/disk. Based on
all testing done for this benchmark essay, XFS appears to be the most
appropriate filesystem to install on 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 on large files (>500MB)
* This FS
gets a good second place for operations on 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 only support this
conclusion.
References
Benoit, M. (2003). Linux File System
Benchmarks.
Piszcz, J. (2006). Benchmarking Filesystems Part II. Linux
Gazette, 122 (January 2006).