Homepage: webng.com/linuxhelp


 SOME AMAZING FILESYSTEM BENCHMARKS 


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


FilesystemCopy 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)14821368834870
REISER4 (lzo)13827856803484
Linux-2.6.13-15-default kernel
REISER4 (tails)14867363783365
REISER414869255672556
NTFS-3g13337721426585767>194
NTFS781779173XXX
REISER318479398856322
XFS22079917311990106
JFS2288062029597127
EXT318281674734351
EXT220181682733967
FAT322539881581188195
Linux-2.6.20-mm1 kernel
REISER4 (tails)15567399814179
REISER415169285813265
NTFS-3g11537721488597844>195
REISER3182793103816523
XFS2107991591098988
JFS22680621695100133
EXT4 (extents)16280655693632
EXT417481670744250
EXT317781662764147
EXT217281672723752
FAT32207988105978857


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%.


FilesystemKernelCopy 2 to 6
(seconds)
Disk Usage
(MB)
Copy 6 to 6
(seconds)
tar -czf
(seconds)
tar -xzf
(seconds)
Delete All
(seconds)
REISER4linux-2.6.13-1514869255672556
linux-2.6.20-mm115169285813265
REISER4 (tails)linux-2.6.13-1514867363783365
linux-2.6.20-mm115567399814179


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.93cSequential CreateRandom Create
SuSE 10.0CreateReadDeleteCreateReadDelete
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:02232393013798425651505172510119
REISER4 (gzip)128k:131072:0144525244981797764131414867377
Linux-2.6.20-mm1 kernel
REISER4128k:131072:0843198871715461014156918645
EXT4128k:131072:01927181814797419171781114118
Linux-2.6.13-15-default kernel
REISER4128k:131072:0801219021915811012646617904
REISER3128k:131072:02806701351231186311531
JFS128k:131072:0361441161109128457011320
XFS128k:131072:021835308942527247111101
EXT2128k:131072:0254507681377132534984812510
EXT3128k:131072:01966974413769519870771114217
FAT32128k:131072:0/54993948229497728934309495
NTFS-3g128k:131072:0700770474435903804350
 
 
Version 1.93cSequential OutputSequential InputRandom
Seeks
Concurrency1Per ChrBlockRewritePer ChrBlock
SizeK/sec%CPK/sec%CPK/sec%CPK/sec%CPK/sec%CP/sec%CP
Linux-2.6.20 kernel (Laurent Riffard's Reiser4 patch)
REISER4 (lzo)1G1139916326836907745490898232729883664277
REISER4 (gzip)1G99999696023646294183398219167873249332
Linux-2.6.20-mm1 kernel
REISER41G443985951252846751041956680472264
EXT41G3959952148142719851549956587452334
Linux-2.6.13-15-default kernel
REISER41G2849657751112843294389963692102196
REISER31G5079853815142699651639926390762274
JFS1G1149945786992879241622936385542343
XFS1G9129659081102716951292936393652062
EXT21G1068945443282737151587926289652263
EXT31G4289949787152682851536916280052243
FAT321G966985054020244781015539363883151955
NTFS-3g1G2664906072038331629935793741690


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 TOTALUSERSYSCPU%
Linux-2.6.20 (Riffard's patch)
REISER4 (lzo)1,938321111
REISER4 (gzip)2,295324010
Linux-2.6.20-mm1 kernel
REISER43,46221664
EXT44,40831,39831
Linux-2.6.13-15-default kernel
REISER43,70121865
EXT24,092379019
JFS4,2252952
EXT34,42131,34830
XFS4,62521162
REISER36,17821462
FAT3212,34248,76571
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, treated 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)
Reiser4Ext3 Reiser4
(LZO)
Reiser4Ext3 Reiser4
(LZO)
Reiser4Ext3 Reiser4
(LZO)
Reiser4Ext3
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)
Reiser4Ext3 Reiser4
(LZO)
Reiser4Ext3 Reiser4
(LZO)
Reiser4Ext3 Reiser4
(LZO)
Reiser4Ext3
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)
Reiser4Reiser4
extent
Reiser3Ext3
writeback
Ext3
journal
Ext3
ordered
Reiser4Reiser4
extent
Reiser3Ext3
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)
Reiser4Reiser4
extent
Reiser3Ext3
writeback
Ext3
journal
Ext3
ordered
Reiser4Reiser4
extent
Reiser3Ext3
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
 Reiser4ReiserFSext3XFSJFS
copy33.3939.5539.4243.5048.15
sync1.543.159.052.083.05
recopy131.0975.1579.96102.37108.39
recopy233.1577.6298.84108.00114.96
sync2.893.848.152.403.86
du2.052.463.313.732.42
delete7.415.223.718.7515.33
tar52.2590.8374.93157.61135.86
sync6.774.191.670.9538.18
Overall171.28302.53319.71429.79470.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