Linux各種文件系統(tǒng)(ext3,ReiserFS,jfs,xfs)的性能
2006-07-28 08:55
以下文章是我自己翻譯的，后面有英文的原文。不當(dāng)之處，敬請(qǐng)指教.
應(yīng)該不是太新的文章，但是我我是2006-07-12的上午才看到的。哎........
2006-07-12
15:00
翻譯完成
--------------------------------------------------------------------------------------------------------------
腸子都悔青了，昨天剛剛新加的硬盤(pán)上面的文件系統(tǒng)還是被我搞成了ext3。如果我能造一天注意到這篇文章的話........
----------------------------------------------------------------------------------------------------------------
Debian
Administration
System Administration Tips and
Resources
現(xiàn)在還可以得到的許多Linux filesystems 比較，但是他們中大多數(shù)是古老的，基于為人任務(wù)的或者在更老的情況下完成。
這篇基準(zhǔn)測(cè)試文基于與老一代的適合一臺(tái)文件服務(wù)器的11項(xiàng)硬件(奔騰II/III，EIDE硬盤(pán))。
從最初編制到出版，文章已經(jīng)產(chǎn)生許多變化，意見(jiàn)和建議改進(jìn)。我目前正努力進(jìn)行一些新的試驗(yàn)。(回答在原文范圍的問(wèn)題)。
結(jié)果將在大約在(2006年5月8日)可提供
漢斯
為什么要做基準(zhǔn)測(cè)試？
我發(fā)現(xiàn)quantitative and reproductible benchmark基準(zhǔn)使用2.6.x kernel。
Benoit在2003年在有512 MB RAM 的PIII 500服務(wù)器上使用大文件(1 + GB)實(shí)現(xiàn)12次試驗(yàn)。
這次試驗(yàn)信息十分豐富，但是結(jié)果對(duì)2.6.x kernel開(kāi)始，主要適用于底座， 專門(mén)操作大的銼(例如，多媒體，科學(xué)，數(shù)據(jù)庫(kù))。
Piszcz
在2006年實(shí)現(xiàn)21項(xiàng)任務(wù)(有768 MB RAM 和一個(gè)400GBEIDE-133硬盤(pán)在PIII-500
模擬多種文件操作)。到目前為止，這測(cè)試看起來(lái)是在2.6.x kernel上的最全面的工作。 但是， 很多任務(wù)是人造的(例如，
復(fù)制和刪除10，000個(gè)空目錄，新建10，000個(gè)文件，遞歸分割文件)，把這些結(jié)論應(yīng)用到現(xiàn)實(shí)世界可能是無(wú)意義的。
因此，
這里測(cè)試的基準(zhǔn)的目標(biāo)是驗(yàn)證一些Piszcz(2006)的結(jié)論， 通過(guò)專門(mén)應(yīng)用于現(xiàn)實(shí)世界在小型企業(yè)文件服務(wù)器(看見(jiàn)任務(wù)描述)里找到。
測(cè)試基礎(chǔ)
* 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)
選擇的測(cè)試任務(wù)描述
*在一個(gè)大文件(ISO 鏡像文件，700
MB)的從第2個(gè)磁盤(pán)復(fù)制到這個(gè)試驗(yàn)磁盤(pán)
*再?gòu)脑诹硪粋€(gè)位置再?gòu)?fù)制這個(gè) ISO 一次
*刪除這個(gè)ISO 的兩個(gè)副本
*操作一文件樹(shù)(有7500 文件，900 目錄，1.9GB)，從第2 磁盤(pán)復(fù)制到這個(gè)試驗(yàn)磁盤(pán)
*再?gòu)脑诹硪粋€(gè)位置再?gòu)?fù)制這個(gè)文件樹(shù)
一次
*刪除這個(gè)文件樹(shù)的兩個(gè)副本
*用遞歸的方法遍歷文件樹(shù)目錄和文件樹(shù)的全部?jī)?nèi)容，復(fù)制到這個(gè)試驗(yàn)磁盤(pán)
*匹配通配符，在文件樹(shù)查找具體的文件
*用(mkfs)
建立filesystem(全部FS都使用默認(rèn)值)
*mount filesystem
*Umount filesystem
上述11項(xiàng)任務(wù)(從建立filesystem到umounting filesystem)的順序，編寫(xiě)為Bash script運(yùn)行完成3
次(報(bào)告平均成績(jī))。 每個(gè)順序花費(fèi)大約7分種，完成任務(wù)的時(shí)間用秒計(jì)算， GNU time utility (version 1.7) 記錄任務(wù)時(shí)的CPU
的利用百分比。
結(jié)果
分區(qū)能力
(在filesystem
創(chuàng)造之后)初始化分區(qū)并重新劃分block的過(guò)程里，Ext3有最差的初始利用率(92.77%)， 其它的filesystem
幾乎可是使用全部的容量(ReiserFS = 99.83%，JFS = 99.82%，XFS = 99.95%)。
結(jié)論：
為了使用你的分區(qū)的的最大容量，選擇ReiserFS，JFS或者XFS。
建立文件系統(tǒng)，mount和unmounting
在20GB的分區(qū)創(chuàng)造filesystem測(cè)試，劃分為Ext3帶14.7秒， 與為相比其他filesystem多2秒或更少。(ReiserFS =
2.2，JFS = 1.3，XFS = 0.7)。
不過(guò)，掛載ReiserFS 要比其他的FS多花費(fèi)5-15倍時(shí)間(2.3秒)(Ext3 =
0.2, JFS = 0.2, XFS = 0.5)，umount以及要比其他的FS多花費(fèi)2 倍時(shí)間(0.4秒)。
所有的FS都花費(fèi)差不多CPU占用來(lái)創(chuàng)建FS(59%（ReiserFS） -74%（JFS）)，掛載FS(在6和9%之間)。 不過(guò)，Ext3
和XFS多用2倍的CPU占用 給umount(37% 和45%)， ReiserFS和JFS(14% 和27%)。
結(jié)論：
對(duì)創(chuàng)建FS性能和mounting/unmounting來(lái)說(shuō)，選擇JFS或者XFS。
大文件操作性能(ISO image，700 MB)
把大文件復(fù)制到Ext3(38.2秒)和ReiserFS(41.8)，
要比JFS和XFS(35.1和34.8)需要更多時(shí)間。使用XFS有助于提高在相同的磁盤(pán)上復(fù)制相同的文件(XFS=33.1,Ext3 = 37.3，JFS =
39.4，ReiserFS = 43.9)相比。 在JFS和XFS上刪除那些ISO 大約要快100
倍(0.02秒)，（ReiserFS1.5秒，Ext32.5秒）！所有FS復(fù)制時(shí)的CPU利用(在46和51%之間)，再?gòu)?fù)制時(shí)(在38%到50%之間)。當(dāng)其他FS使用大約10%時(shí)，ReiserFS使用49%的CPU。
比他FS大約少5到10%)，JFS使用較少的CPU。
結(jié)論： 對(duì)大文件操作性能來(lái)說(shuō)，最好選擇JFS或者XFS。
如果你需要使CPU利用減到最小，更推薦JFS。
目錄樹(shù)(7500個(gè)文件，900份目錄，1.9GB)的操作
最初復(fù)制目錄樹(shù)時(shí)，Ext3(158.3秒)和XFS(166.1秒)更迅速，
ReiserFS和JFS(172.1和180.1)。在第二次復(fù)制的時(shí)候有相似的結(jié)果。（Ext3=120秒，XFS = 135.2，ReiserFS =
136.9 和JFS = 151)。但是， 移動(dòng)目錄樹(shù)時(shí)Ext3(22秒)相比ReiserFS(8.2秒，
XFS(10.5秒)和JFS(12.5秒))大約多2倍時(shí)間！所有FS在復(fù)制和再?gòu)?fù)制目錄樹(shù)時(shí)都使用較多的CPU
(復(fù)制在27和36%之間)，(再?gòu)?fù)制在29%-JFS和45%-ReiserFS之間)。
令人吃驚，ReiserFS
和XFS使用更多的CPU 刪除目錄樹(shù)(86% 和65%)，
而其他FS只使用大約15%的(Ext3和JFS)。再次，與任何其他FS相比較，JFS的明顯使用較少CPU。
當(dāng)有較多的數(shù)量較小頁(yè)面時(shí)適合ReiserFS。這個(gè)差別在目錄樹(shù)的再?gòu)?fù)制和移動(dòng)里的ReiserFS將有更高的速度。
結(jié)論：對(duì)在大容量的目錄樹(shù)操作來(lái)說(shuō)，選擇Ext3或者XFS。
來(lái)自其他作者的基準(zhǔn)測(cè)試已經(jīng)證明如果使用ReiserFS，對(duì)大量的小文件更為合適。但是，目前包括各種各樣尺寸(10KB在5
MB)數(shù)千文件的目錄樹(shù)操作上，建議使用Ext3或者XFS可能獲得更好的性能。如果JFS的CPU占用減到最小，這種FS帶著相當(dāng)高的性能。
目錄列表和文件查找
遞歸顯示目錄的目錄列表，ReiserFS(1.4秒)和XFS更迅速的1.8)，
Ext3和JFS(2.5和3.1)。文件查找有著相同的結(jié)果。在文件查找項(xiàng)目，
ReiserFS(0.8秒)相比XFS(2.8)和Ext3(4.6秒)和JFS(5秒)更迅速。
Ext3和JFS有更好CPU占用：目錄列表(35%)，文件查找(6%)。 XFS目錄列表(70%)使用更多的CPU，文件查找(10%)。 ReiserFS
看起來(lái)是占用CPU最多的FS，目錄列表71%，文件查找36% 。
結(jié)論： 結(jié)果表明那，
對(duì)于這些CPU占用任務(wù)來(lái)說(shuō)，(ext3和JFS)filesystems 能更少的使用CPU的。 XFS作為好備選，帶有相對(duì)適中的性能和CPU的占用。
總的結(jié)論
這些結(jié)果從Piszcz(2006)關(guān)于分解的Ext3，ReiserFS的磁盤(pán)能力報(bào)告一樣。
這兩篇文章兩篇已經(jīng)顯示JFS是最低的CPU利用的FS。 最后，這份報(bào)告看起來(lái)沒(méi)有顯示出ReiserFS的high page faults activity
由于一個(gè)分區(qū)只能有一個(gè)filesystem，認(rèn)識(shí)每種filesystem的優(yōu)缺點(diǎn)很重要。如果，以這篇文章的全部測(cè)試為基準(zhǔn)，
XFS看起來(lái)是家庭或者小型企業(yè)最適合的應(yīng)用于文件服務(wù)器的filesystem：
*它使用你的服務(wù)器硬盤(pán)(s)的擁有最大的容量
*創(chuàng)建FS，mount和unmount很迅速
*操作大文件最迅速的FS(>500 MB)
*這FS得第二名地方給經(jīng)營(yíng)關(guān)于許多在適度尺寸文件和目錄小
*在CPU占用和目錄列表或者文件搜尋性能之間比較平衡，
*沒(méi)有最小CPU要求，老一代硬件也可十分接受
Piszcz(2006)當(dāng)時(shí)沒(méi)有明確推薦XFS，他只是說(shuō)："就個(gè)人來(lái)說(shuō)，我仍然愿意選擇同時(shí)具備性能和可伸縮性的XFS"。
現(xiàn)在我只能支持這個(gè)結(jié)論。
參考
貝努瓦，M.(2003)。 Linux 文件系統(tǒng)基準(zhǔn)。
Piszcz，J.(2006)。 基準(zhǔn)問(wèn)題測(cè)試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).