Some Filesystem Benchmarks.

Free Web Hosting | free host | Free Web Space | Web Hosting

Homepage: http://linuxhelp.150m.com/

SOME AMAZING FILESYSTEM BENCHMARKS.

Here are the results of the first tests (smaller is better):

Filesystem	Copy 2 to 6 (seconds)	Disk Usage (MB)	Copy 6 to 6 (seconds)	tar -czf (seconds)	tar -xzf (seconds)	Delete All (seconds)
Linux-2.6.20 kernel (Laurent Riffard's Reiser4 patch)
REISER4 (gzip)	148	213	68	83	48	70
REISER4 (lzo)	138	278	56	80	34	84
Linux-2.6.13-15-default kernel
REISER4 (tails)	148	673	63	78	33	65
REISER4	148	692	55	67	25	56
NTFS-3g	1333	772	1426	585	767	>194
NTFS	781	779	173	X	X	X
REISER3	184	793	98	85	63	22
XFS	220	799	173	119	90	106
JFS	228	806	202	95	97	127
EXT3	182	816	74	73	43	51
EXT2	201	816	82	73	39	67
FAT32	253	988	158	118	81	95
Linux-2.6.20-mm1 kernel
REISER4 (tails)	155	673	99	81	41	79
REISER4	151	692	85	81	32	65
NTFS-3g	1153	772	1488	597	844	>195
REISER3	182	793	103	81	65	23
XFS	210	799	159	109	89	88
JFS	226	806	216	95	100	133
EXT4 (extents)	162	806	55	69	36	32
EXT4	174	816	70	74	42	50
EXT3	177	816	62	76	41	47
EXT2	172	816	72	72	37	52
FAT32	207	988	105	97	88	57

Each test was preformed 5 times and the average value recorded.

The tests were run on a SuSE 10.0 box (booted single mode).
First, the tests were run using the drivers of the 2.6.13-15-default kernel.
Second, they were repeated with the drivers of Morton's linux-2.6.20-mm1 kernel.
This provides a measure of the progress made between the 2.6.13 and 2.6.20 kernels.

Subsequent to this, tests were run with Laurent Riffard's Reiser4 patch to the default linux-2.6.20 kernel. These provided benchmarks for Reiser4 when running transparent gzip, and lzo, compression. Laurent's Reiser4 patch for the 2.6.20 kernel can be found here. There are also patches for a few others kernels here.

For technical reasons du had to be replaced by df in the tests involving compression. The space occupied by the data is df minus the size of the filled journal = 16MB. 16MB is the difference between df and du -s in the case when no compression is used.

NTFS and NTFS-3g are both the NTFS filesystem, but with different drivers.
All filesystems (except NTFS and JFS) were formated with the default tools of SuSE 10.0.
For NTFS-3g the ntfs-3g-0.20070118-BETA/fuse driver was used.
For NTFS the native 32-bit Windows XP-SP2 driver was used.

Initially, the object was to see how much disk space the various filesystems used to store a given amount of data. The data itself (without filesystem meta-data, block alignment wastage, etc) amounted to 655 MB (1 MB = 1024 x 1024 bytes). It consisted of 3 versions of the linux kernel sources (linux-2.6.13-15, linux-2.6.19 and linux-2.6.20-rc4-mm1).

In order to test this, it was necessary to format a partition (the 6th) with the filesystem to be tested, then copy the sources from where they were (/usr/src/test/ of partition 2) to partition 6 and measure the disk space used. The time it took to preform the copy is recorded in column 1. The disk space used is recorded in column 2.

In the NTFS case, the sources had to be copied from partition 1, an NTFS partition, to partition 6.

The 2nd partition was a Reiser3 partition (my SuSE 10.0 partition). Although copying from one partition to another, is of interest, it is more important to find out how fast copying within the filesystem, is. Hence, the sources are copied from one part of the 6th partition, to another. The time it took to preform the copy is recorded in column 3.

At this point a couple of other tests are tossed into the mix. Column 4 measures the time taken to tar and gzip the sources. Column 5 measures the the time taken to unbundle the tarred and gzipped sources. Column 6 measures the time taken to delete everything just written to partition 6.

An X indicates the test was not carried out.

RESULTS.

The first thing to note, is how much better than all the other filesystems, Reiser4 (without compression) is. With transparent compression, Reiser4 is truly in a class of its own. Reiser4, clearly trounces all competing filesystems.

The second thing to note, is that every single benchmark for reiser4 has grown worse in the passage from the 2.6.13 kernel, to the 2.6.20 kernel. Some results have deteriorated by as much as 55%.

Filesystem	Kernel	Copy 2 to 6 (seconds)	Disk Usage (MB)	Copy 6 to 6 (seconds)	tar -czf (seconds)	tar -xzf (seconds)	Delete All (seconds)
REISER4	linux-2.6.13-15	148	692	55	67	25	56
REISER4	linux-2.6.20-mm1	151	692	85	81	32	65
REISER4 (tails)	linux-2.6.13-15	148	673	63	78	33	65
REISER4 (tails)	linux-2.6.20-mm1	155	673	99	81	41	79

So, it appears that certain kernel developers are deliberately crippling Reiser4. Or, perhaps, Hans Reiser and the Namesys developers are just much better coders, and the kernel developers adjustments, have just made good code, bad. Certainly, many people have been lying about the qualities and abilities of the Reiser4 filesystem, and such active sabotage, by a few developers, is the most likely explanation.

Also, note that some older filesystems, no longer under development, showed significant increases in speed (fat32, ext2, ext3 and xfs). This shows that the quality of hardware drivers, etc, is on the whole, improving. It also means that the deterioration of the reiser4 driver is worse than at first apparent.

The reiser4 filesystem (in particular, the linux-2.6.13-15 version) clearly outperforms all other filesystems. Using reiser4, rather than ext3, saves you a massive 816 - 692 = 124 MB of disk space (a 15% saving, mainly, from eliminating block alignment wastage).

Not only do you save 124 MB, but your copy is finished significantly quicker. And, if you use the "tails" option

mkfs.reiser4 -o formatting=tails /dev/sda6

the saving in disk space (over ext3) is an incredible 143 MB. And if you use compression:

mkfs.reiser4 -o create=ccreg40,compress=gzip1 /dev/sda6
mkfs.reiser4 -o create=ccreg40,compress=lzo1 /dev/sda6

the saving in disk space (over ext3) is an truly amazing 816 - 213 = 603 MB (a 74% saving), and this, with little, or no, loss of performance.

As you can see, REISER4 is a truly remarkable filesystem.

This is the real reason that REISER4 has not been included in the Linux kernel.
This is the real reason that Hans Reiser languishes in an Oakland prison cell at this time.

Not only does Reiser4 support transparent compression, but it also supports encryption. I have not played with the encryption, yet. Interestingly, although the source for the cryptcompress plugin, ccreg40, appears to be in 2.6.13-15-default, it has not been compiled in, and is thus not available for use in SuSE 10.0.

It should be stressed that the cryptcompress source has been entirely removed from linux-2.6.20-mm1.

I have now made Reiser4, with gzip compression, the default filesystem on my test box (which sees much more activity than the others). The option I chose is:

mkfs.reiser4 -o create=ccreg40,compress=gzip1,compressMode=conv /dev/sda6

I am not sure that compressMode=conv is any better than the default compressMode=col8.

Note that NONE of the filesystem formating programs, mkfs.ext2, mkfs.ext3, mkfs.ext4, mkfs.vfat (FAT32), mkntfs (NTFS) provide a stop, to save you from a simple typo. They just proceed to reformat the partition, as requested. So, simply hitting a 2 instead of a 3, WILL end up destroying all your work on the 2nd partition.

The filesystems reiser4, reiserfs, xfs and jfs, all try to save you from such a disaster. This shows a difference in attitude between Reiser and the ext4 developers. One cares about your work. The others really don't, and are setting you up for a fall.

The NTFS filesystem and driver, performed very poorly, especially when copying from one NTFS partition to another. It is possible the problem is not filesystem related, but due to the SATA driver that shipped with the motherboard (or Windows XP). Or, it might be a problem related to running a 32-bit operating system on a 64-bit machine. Who knows?

Interestingly enough, the NTFS/fuse project is most probably another effort designed to have NTFS preform poorly under Linux. By design, NTFS/fuse is a user space driver, and thus will never compete favorably with Microsoft's kernel drivers. The Linux NTFS kernel driver was knocked on the head some years ago, after claims, probably false, of how dangerous it was to use. Anyway, instead of fixing the supposed problems, the work to that point was just thrown away and the NTFS/fuse project started.

Greg Kroah-Hartman, has promised to write kernel drivers for any company that provides specifications for their hardware/filesystems. Well, the specifications for the NTFS are known (eg, they can be found here). So, we assume that Greg and the boys, will be releasing a kernel driver for NTFS, any day now.

JFS was formated with a later version of mkfs.jfs (1.1.11), as the default did not work.

As you can see, FAT32, is a poorly designed filesystem (with poor performance, compared to the Linux competitor of it's time, EXT2).

The >194 in the "Delete All" column for ntfs-3g, means that the deletion failed, and that it took (an average of) 194 seconds to delete what was deleted (which was nearly everything). Error messages, like the following, were recorded:

rm: cannot remove `/6/copy3/linux-2.6.19/Documentation/nbd.txt': Operation not supported

The guts of the script used to obtain the results, was:

#!/bin/bash

function t() { echo "$1";/usr/bin/time -f "REAL:%e\tUSER:%U\tSYS:%S\tCPU:%P" $1; }   

echo "cd /"
cd /
t "cp -r /usr/src/test/linux-* /6"
echo "cd /6;du -s;cd /"
cd /6;du -s|awk '{printf("%d %.0f:MB\n",$1,$1/1024)}';cd /
echo "mkdir /6/copy2;cd /6/copy2"
mkdir /6/copy2;cd /6/copy2
t "cp -r /6/linux-* /6/copy2"
t "tar -czf 6.tar.gz linux-*"
echo "mkdir /6/copy3"
mkdir /6/copy3
t "tar -xzf 6.tar.gz -C /6/copy3"
t "rm -fr /6/*"
echo "cd /;umount /dev/sda6"
cd /;umount /dev/sda6

The raw results can be found here.

For some more traditional benchmarks, I ran bonnie++ (1.93c) on the filesystems (larger is better, except for CP percentages).

Version 1.93c		Sequential Create						Random Create
SuSE 10.0		Create		Read		Delete		Create		Read		Delete
files:	num:max:min/dirs	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP
Linux-2.6.20 kernel (Laurent Riffard's Reiser4 patch)
REISER4 (lzo)	128k:131072:0	2232	39	3013	79	8425	65	150	5	172	5	1011	9
REISER4 (gzip)	128k:131072:0	1445	25	2449	81	7977	64	131	4	148	6	737	7
Linux-2.6.20-mm1 kernel
REISER4	128k:131072:0	843	19	887	17	1546	10	141	5	69	1	864	5
EXT4	128k:131072:0	192	71	818	14	797	4	191	71	78	11	141	18
Linux-2.6.13-15-default kernel
REISER4	128k:131072:0	801	21	902	19	1581	10	126	4	66	1	790	4
REISER3	128k:131072:0	280	6	70	1	351	2	311	8	63	1	153	1
JFS	128k:131072:0	361	4	411	6	1109	1	284	5	70	1	132	0
XFS	128k:131072:0	218	3	530	8	942	5	272	4	71	1	110	1
EXT2	128k:131072:0	254	50	768	13	771	3	253	49	84	8	125	10
EXT3	128k:131072:0	196	69	744	13	769	5	198	70	77	11	142	17
FAT32	128k:131072:0/5	49	93	94	82	294	97	72	89	34	30	94	95
NTFS-3g	128k:131072:0	70	0	77	0	4744	3	59	0	38	0	435	0


Version 1.93c		Sequential Output						Sequential Input				Random Seeks
Concurrency	1	Per Chr		Block		Rewrite		Per Chr		Block		Random Seeks
	Size	K/sec	%CP	K/sec	%CP	K/sec	%CP	K/sec	%CP	K/sec	%CP	/sec	%CP
Linux-2.6.20 kernel (Laurent Riffard's Reiser4 patch)
REISER4 (lzo)	1G	113	99	163268	36	90774	54	908	98	232729	88	3664	277
REISER4 (gzip)	1G	99	99	96960	23	64629	41	833	98	219167	87	3249	332
Linux-2.6.20-mm1 kernel
REISER4	1G	443	98	59512	5	28467	5	1041	95	66804	7	226	4
EXT4	1G	395	99	52148	14	27198	5	1549	95	65874	5	233	4
Linux-2.6.13-15-default kernel
REISER4	1G	284	96	57751	11	28432	9	438	99	63692	10	219	6
REISER3	1G	507	98	53815	14	26996	5	1639	92	63907	6	227	4
JFS	1G	1149	94	57869	9	28792	4	1622	93	63855	4	234	3
XFS	1G	912	96	59081	10	27169	5	1292	93	63936	5	206	2
EXT2	1G	1068	94	54432	8	27371	5	1587	92	62896	5	226	3
EXT3	1G	428	99	49787	15	26828	5	1536	91	62800	5	224	3
FAT32	1G	966	98	50540	20	24478	10	1553	93	63883	15	195	5
NTFS-3g	1G	26	6	49060	7	20383	3	1629	93	57937	4	169	0

Each test (except NTFS-3g and FAT32, which took too long) was preformed 5 times and the average value recorded.

All the benchmarks (except FAT32) were obtained by running the command:

bonnie++ -n128:128k:0

The -n128 means that the test wrote, read and deleted 128k (131,072) files. These were first sequentially, then randomly, written/read/deleted to/from the directory.

The :128k:0 means that every file had a random size between 128k (131,072 bytes) and zero. So the average file-size was 64k.

Except for FAT32, the tests were preformed in one directory. The FAT32 filesystem created by mkfs.vfat had a limit, of about 28,000 files, per directory, so it was necessary to preform the test in 5 separate directories, with the command:

bonnie++ -n128:128k:0:5

Theoretically, a FAT32 directory, should be able to hold 65,535 files.

RESULTS.

Well, these results have a simple message: Use Reiser4 with compression (either gzip or lzo).

Consider that sequential reads, of 232,729 K/sec, are FOUR times the physical read rate, 63,160 K/sec, of the hard drive. And, sequential writes, of 163,268, are many times the physical write rate. This is only possible, of course, due to the use of compression.

So, Reiser4 with compression, is the runaway winner. What of the rest?

Interpreting the rest of these results, is somewhat difficult, as it depends on what you want from a filesystem. Journaling filesystems, like all of those tested (except EXT2 and FAT32) are much more robust to system failure and do not need those regular, lengthy, filesystem checks. However, keeping a journal, adds overhead when creating files (when deleting files it actually helps, as you need only find the file entries in the journal, and delete these entries, as opposed to finding them in multiple directory listings, potentially spread right across the hard-disk).

The fact that the journaling filesystem Reiser3 can create files faster (randomly and sequentially) than the non-journaling filesystem EXT2 is a testament to a well designed filesystem, and well written code.

The plan was to also test Minix, but two different versions of mkfs.minix refused to format the partition, so I didn't bother.

The average total time taken to complete each test (in seconds) is given below:

FILESYSTEM	TOTAL	USER	SYS	CPU%
Linux-2.6.20 (Riffard's patch)
REISER4 (lzo)	1,938	3	211	11
REISER4 (gzip)	2,295	3	240	10
Linux-2.6.20-mm1 kernel
REISER4	3,462	2	166	4
EXT4	4,408	3	1,398	31
Linux-2.6.13-15-default kernel
REISER4	3,701	2	186	5
EXT2	4,092	3	790	19
JFS	4,225	2	95	2
EXT3	4,421	3	1,348	30
XFS	4,625	2	116	2
REISER3	6,178	2	146	2
FAT32	12,342	4	8,765	71
NTFS-3g	>10,414	>5	>52	>0

Another set of bonnie++ benchmarks (of dubious value, as the files created, read and deleted, all have size zero) can be found here.

The tests above were run on a AMD Socket AM2 Athlon 64 3500+ system with a Seagate 250 Gig SATA drive and 512 MB RAM. The tests were run from the console, after booting in single mode. Some details concerning the hard-drive, follow:

hdparm -tT /dev/sda6

/dev/sda6:

 Timing cached reads:   2944 MB in  2.00 seconds = 1471.91 MB/sec
 Timing buffered disk reads:  190 MB in  3.01 seconds =  63.16 MB/sec

Strangely, even when run under SuSE 10.0, the hdparm program from Debian, measures "timing cached reads" at half the speed (of SuSE 10.0's hdparm program). The source code of one, clearly contains an error.

hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       ST3250824AS
        Serial Number:      62315ARE
        Firmware Revision:  3.AAH
Standards:
        Supported: 7 6 5 4
        Likely used: 7
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:   16514064
        LBA    user addressable sectors:  268435455
        LBA48  user addressable sectors:  488397168
        device size with M = 1024*1024:      238475 MBytes
        device size with M = 1000*1000:      250059 MBytes (250 GB)
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum   
        R/W multiple sector transfer: Max = 16  Current = 1
        Recommended acoustic management value: 254, current value: 0
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=240ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
                SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    DOWNLOAD_MICROCODE
                SET_MAX security extension
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    SATA-I signaling speed (1.5Gb/s)
           *    Native Command Queueing (NCQ)
           *    Phy event counters
           *    Software settings preservation
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
        not     supported: enhanced erase
Checksum: correct

Hans Reiser's Benchmarks.

Since 2003, Hans Reiser has presented benchmarks which show that Reiser4 is a significant advance in the development of filesystems. In particular, Hans has tested Reiser4 against ext3 and has shown Reiser4 to be, far and away, the better product.

For the sin of creating a better Linux product, one not under Red Hat control, various associates of Red Hat, treat Hans Reiser as a pariah and set out to destroy his product. And eventually perhaps, Reiser himself, who has been framed for a "murder" that never happened.

Red Hat, has a history of trying to destroy Linux competitors, for example, Trolltech (in particular, it's desktop KDE). Red Hat, also has a history of crippling their own Linux product for the benefit of Micro$oft, the RIAA and the MPAA (crippling Linux's NTFS capabilities, crippling MP3 features, crippling video codecs and players, etc).

So, even though for many years it has been known that Reiser4 is hugely better than ext3, the LIARS in the press, the LIARS at Red Hat and the LIARS who swarm all over every bulletin board and public venue, all lied, and still lie, about Reiser's filesystems, in an attempt to destroy the Reiser filesystems.

So that people cannot say that the evidence was not there, I have resurrected some of Hans Reiser's benchmarks.

Feb 11, 2006: Reiser's Mongo benchmark comparing ext3 vs Reiser4 with LZO compression.

Here, Reiser used a linux-2.6.15-mm4 kernel and plugins disk=format40 (the default), create=create_ccreg40 (now create=ccreg40), compressMode=col8 (the default, now compressMode=lattd) and compress=lzo1 (the default). The filesystem was created with the command:

mkfs.reiser4 -y -o create=create_ccreg40,compressMode=col8

The total create, copy, read and delete times are the most importance (to most people). These figures have been lightly tinted with red. In presenting Reiser's results, I have changed Reiser's presentation, but not the data.

In the table, smaller numbers are better. A number is marked red, if that result is slower than for Reiser4-LZO. A number is marked green, if that result is faster than for Reiser4-LZO. The best result for a category is underlined.

TOTAL TIME was originally called REAL_TIME. The Mongo pearl scripts can be found here.

A.MKFS=mkfs.reiser4 -y -o create=create_ccreg40,compressMode=col8 MOUNT_OPTIONS=noatime FSTYPE=Reiser4

B.MKFS=mkfs.reiser4 -y MOUNT_OPTIONS=noatime FSTYPE=Reiser4 (unixfile regular file plugin)
C.MOUNT_OPTIONS=noatime,data=ordered (only journals metadata changes) FSTYPE=ext3
#0:
	TOTAL TIME (SECS)			CPU TIME (SECS)			CPU UTIL (SECS)			DISK USAGE (MB)
MONGO	Reiser4 (LZO)	Reiser4	Ext3	Reiser4 (LZO)	Reiser4	Ext3	Reiser4 (LZO)	Reiser4	Ext3	Reiser4 (LZO)	Reiser4	Ext3
CREATE	`53.36`	`65.85`	`226.73`	`28.79`	`14.19`	`31.90`	`94.36`	`24.06`	`14.63`	`776`	`1979`	`2192`
COPY	`137.6`	`212.32`	`403.31`	`40.91`	`29.29`	`39.89`	`59.94`	`15.40`	`10.97`	`1552`	`3957`	`4384`
READ	`161.17`	`175.19`	`173.58`	`48.35`	`20.94`	`9.43`	`33.23`	`16.18`	`9.67`	`1552`	`3957`	`4384`
STATS	`24.12`	`22.58`	`22.36`	`6.76`	`6.36`	`4.22`	`27.97`	`28.11`	`18.91`	`1552`	`3957`	`4384`
DELETE	`155.26`	`169.39`	`153.55`	`38.76`	`31.94`	`4.19`	`26.33`	`19.96`	`2.74`	`0.004`	`0.004`	`0.00`
#1:DD_MBCOUNT=5000
	TOTAL TIME (SECS)			CPU TIME (SECS)			CPU UTIL (SECS)			DISK USAGE (MB)
LARGE FILES	Reiser4 (LZO)	Reiser4	Ext3	Reiser4 (LZO)	Reiser4	Ext3	Reiser4 (LZO)	Reiser4	Ext3	Reiser4 (LZO)	Reiser4	Ext3
dd_writing_largefile	`116.02`	`165.91`	`180.18`	`38.65`	`19.87`	`23.92`	`92.86`	`14.39`	`13.84`	`1909`	`5120`	`5126`
dd_reading_largefile	`153.76`	`153.14`	`153.91`	`58.11`	`11.16`	`8.54`	`38.73`	`8.67`	`5.89`	`1909`	`5120`	`5126`
#2
DIR=/mnt1 GAMMA=0.2 WRITE_BUFFER=131072 PHASE_APPEND=off SYNC=off PHASE_DELETE=rm NPROC=1 DEV=/dev/hda9 DD_MBCOUNT=5000 FILE_SIZE=8192 REP_COUNTER=1 PHASE_COPY=cp INFO_R4=2.6.15-mm4 cryptcompress-4.patch PHASE_READ=find BYTES=1024000000 PHASE_OVERWRITE=off PHASE_MODIFY=off
Produced by Mongo benchmark suite.

dd_writing_largefile and dd_reading_largefile preform the commands:

dd if=/dev/zero of=DIR/largefile bs=1M count=DD_MBCOUNT
dd if=DIR/largefile of=/dev/null bs=1M count=DD_MBCOUNT

respectively. In the first benchmark DD_MBCOUNT=5000 and in the next DD_MBCOUNT=768.

Jun 17, 2005: Reiser's Mongo benchmark comparing Reiser4 vs Reiser3 vs ext3.

Here, Reiser used a linux-2.6.8.1-mm3 kernel.

A.FSTYPE=Reiser4

B.FSTYPE=Reiser4 MKFS=mkfs.reiser4 -q -o extent=extent40
C.MOUNT_OPTIONS=notail FSTYPE=reiserfs
D.MOUNT_OPTIONS="data=writeback" FSTYPE=ext3
E.MOUNT_OPTIONS="data=journal" FSTYPE=ext3
F.MOUNT_OPTIONS="data=ordered" FSTYPE=ext3
#0:
	TOTAL TIME (SECS)						CPU TIME (SECS)
	Reiser4	Reiser4 extent	Reiser3	Ext3 writeback	Ext3 journal	Ext3 ordered	Reiser4	Reiser4 extent	Reiser3	Ext3 writeback	Ext3 journal	Ext3 ordered
CREATE	`91.6`	`90.50`	`181.64`	`237.43`	`275.72`	`206.65`	`31.13`	`30.04`	`25.71`	`80.22`	`78.73`	`87.23`
COPY	`219.5`	`212.48`	`367.44`	`491.90`	`462.05`	`399.27`	`54.04`	`50.69`	`42.80`	`91.54`	`108.30`	`100.51`
READ	`187.34`	`188.65`	`302.93`	`240.17`	`242.61`	`234.17`	`38.61`	`38.69`	`27.45`	`23.75`	`24.02`	`23.75`
STATS	`23.71`	`22.95`	`27.55`	`22.36`	`22.36`	`22.36`	`10.91`	`10.30`	`7.82`	`7.21`	`7.35`	`7.18`
DELETE	`156.84`	`155.74`	`36.54`	`198.25`	`199.19`	`190.72`	`53.05`	`49.76`	`23.34`	`11.09`	`11.41`	`11.35`
#1:DD_MBCOUNT=768
	TOTAL TIME (SECS)						CPU TIME (SECS)
	Reiser4	Reiser4 extent	Reiser3	Ext3 writeback	Ext3 journal	Ext3 ordered	Reiser4	Reiser4 extent	Reiser3	Ext3 writeback	Ext3 journal	Ext3 ordered
dd_writing_largefile	`30.09`	`30.27`	`38.70`	`40.38`	`74.41`	`39.45`	`5.24`	`5.22`	`5.22`	`6.74`	`7.30`	`7.53`
dd_reading_largefile	`28.38`	`27.50`	`28.66`	`27.81`	`27.87`	`28.35`	`4.37`	`4.28`	`4.43`	`3.98`	`3.91`	`4.09`
#2
REP_COUNTER=1 PHASE_COPY=cp INFO_R4=2.6.8.1-mm3 + parse_options.patch FILE_SIZE=8192 DEV=/dev/hda6 PHASE_MODIFY=off DD_MBCOUNT=768 PHASE_APPEND=off PHASE_OVERWRITE=off SYNC=off DIR=/mnt1 PHASE_DELETE=rm NPROC=1 BYTES=1024000000 GAMMA=0.2 PHASE_READ=find WRITE_BUFFER=131072
Produced by Mongo benchmark suite.

Another set of benchmarks, by Grant Miner, from 05 Aug 2003, is available at:

http://kerneltrap.org/node/715

He tested various writing and copying operations on a mozilla source tree of size 295 MB. He used a Linux 2.6.0 kernel, 512 MB memory, 11,531.85 MB partition for tests.

Smaller is better.

Time, in seconds, to complete action
	Reiser4	ReiserFS	ext3	XFS	JFS
copy	33.39	39.55	39.42	43.50	48.15
sync	1.54	3.15	9.05	2.08	3.05
recopy1	31.09	75.15	79.96	102.37	108.39
recopy2	33.15	77.62	98.84	108.00	114.96
sync	2.89	3.84	8.15	2.40	3.86
du	2.05	2.46	3.31	3.73	2.42
delete	7.41	5.22	3.71	8.75	15.33
tar	52.25	90.83	74.93	157.61	135.86
sync	6.77	4.19	1.67	0.95	38.18
Overall	171.28	302.53	319.71	429.79	470.88

Here is the script Grant Miner used:

#!/bin/sh
time='time -f%e,%P '
echo "Copying Tree"
$time cp -a /home/test/mozilla /mnt/test    
echo "Sync"
$time sync
cd /mnt/test &&
echo "recopying tree to mozilla-2"
$time cp -a mozilla mozilla-2 &&
echo "recopying mozilla-2 to mozilla-3"
$time cp -a mozilla mozilla-2 &&
echo "sync"
$time sync &&
echo "du"
$time du mozilla > /dev/null &&
echo "rm -rf mozilla"
$time rm -rf mozilla
echo "tar c mozilla-2"
$time tar c mozilla-2 > mozilla.tar
echo "final sync"
$time sync