Last changes:
Do Feb  5 09:40:01 CET 2004

You may download agesystem and try it yourself. After downloading the package create a directory where to untargz it. You probably want to change first some paths in the Makefile. Maybe you also have to download the GNU Scientific Library. Then either use ''agesystem.sh'' or type ''make agesystem'' followed by ''agesystem -h'' to get additional help.
The ''timing result'' output tells you for every 5% of used blocks in the partition the time needed, cpu needed and number of bytes written. If you send the output to me I can make a histogram out of it.
There is a define ''#define GAUGE'' which actually prevents agesystem from really aging the system.

Usage of agesystem v0.3
         -b blksize                     blocksize to use for buffered i/o
         -c dir_counter                 number of subdirectories to create and use for aging
         -d dirname                     change to directory "dirname"
         -f                             use fixed length of bytes, given in blocksize
         -l minimum_file_size_in_bytes  set minimum file size to minimum_file_size_in_bytes""
         -n number_of_files             maximum number of files to create
         -m mean_file_size_in_bytes     set mean file size to minimum_file_size_in_bytes""
         -o access_mode                 set access mode to  "access_mode" 
            (eg. cw=65, cws=4161, cwa=1089,cwas=5185, cwt=577,cwts=4673)
         -h,-?                          this text
         -s file_no                     start with filenumber "file_no"
         -t                             test input and exit
         -u max_fs_usage                max filesystem usage to reach
         -v                             be verbose
         -y seed                        set random generator seed
         -z                             sync with unmount

The file size distribution looks as shown for the 550 MB case. It is created using three types of files:

1. with 89 % probability choose from normal distribution (tailed) with minimum file size of 0 and average of 2^10 Byte,
2. with 10 % probability choose from normal distribution (tailed) with minimum file size of 2^10 and average of 2^14 Byte and
3. with 1 % probability choose from normal distribution (tailed) with minimum file size of 2^14 and average of 2^17 Byte.

• Ext2's write performance is fairly constant over the used blocks space. For a block size of 1024 I repeated the measurement as it is peculiar, that the performance improves when the partition is almost full! Anyone any idea, why? Please let me know!!! (corresponding Ext2's CPU usage)
  Here and in the following:
  "100x50" always means: a directory hierarchy of 100 dirs in each again 50
  "without-deletion" always means: "gauging" as I introduced it above
• ReiserFS's write performance quickly drops down, probably because of the overhead in adjusting the tree. Omitting the fragments by mounting with "-notail" improves the performance (absolutely and in shape), omitting writing the log with "-nolog" does not always improve the performance which might be due to low statistics and other processes on the test machine, but what is more important in my case, it does not change the shape of the curve. Another good thing, the layout of the directories (completely flat 1000 directories and the 100x50 version mentioned above) have no influence on the shape. For people that judge performance and not the shape (!!!) between the file systems I want to add, that ReiserFS without "-notail" has the lowest internal fragmentations of 10 percent, compared to all other file systems (except ext2 with 1024 block size) which have an internal fragmentation of about 50 percent!!! (corresponding ReiserFS's CPU usage)
• JFS performs quite well for the first half of the plot and then breaks down at 50 percent usage. I did a second measurement restricting the log to 40MB and to 10 MB, because the performance loss could be because of the default log size of 40 percent JFS uses when not given a different option to mkfs.jfs. The difference is almost not visible. I am not aware of the details of JFS but -at first glance, the shape of the curve looks really bad. (corresponding JFS's CPU usage)
• XFS's performance looks pretty much the same as JFS, it also breaks down at 50 percent usage. To be sure I measured again with a 10 MB log size (notice ReiserFS's log size is per default 32 MB). It seems to make a small difference. In a third measurement I also used a completely different partition at the beginning of the (SCSI) disk (as opposed to at the end as usual) with the same number of cylinders of course, which also did not make any significant changes. Though it might be possible, that both -JFS and XFS- are designed for larger partitions but why is XFS then called ''scalable''? Look beyond for tests on bigger partition sizes and find the same problem. (corresponding XFS's CPU usage)

• with 89 % probability choose from normal distribution (tailed) with minimum file size of 0 and average of 2^12 Byte,
• with 10 % probability choose from normal distribution (tailed) with minimum file size of 2^12 and average of 2^16 Byte and
• with 1 % probability choose from normal distribution (tailed) with minimum file size of 2^16 and average of 2^20 Byte. which gives this distribution for large partitions of 1 or 4 GB. The number of directories used is now 10000 directories with hierarchy of 100x100.
  The 1 GB result for the three journaling file systems with no additional options (except once from -notail for a fairer comparison) is shown for the 1 GB case. Again ReiserFS shows a drop down (probably due to the maintaining costs of the tree). Remarkable that all LFS and XFS and also Reiser with -notail scale well over the x-axis. There is a significant change of shape for XFS and LFS compared to the small file-size distribution I used above. (corresponding CPU usage for the 1 GB case)
  
  

  Results for the 4 GB partition

  The 4 GB result for the three journaling file systems with no additional options (except once from -notail for a fairer comparison) is shown for the 4GB case. Notice that for ReiserFS (without -notail) 252738 (4192538 KB) files are created with an internal fragmentation of less than 6 % (which is comparable to the 550 MB small file case).

  FS type	# files	# Bytes	Int. Frag.
  Reiser	252738	4192538 KB	6 %
  Reiser notail	227190	3791069 KB	14 %
  XFS	225394	3757207 KB	15 %
  JFS	219376	3667703 KB	17 %
  Ext3	208314	3482720 KB	21 %

  Overall the 4 GB picture is comparable to the 550 MB. The different curves have the same properties. Again XFS and JFS have a sharp decline at less than 40 % fullness, so that their performance is the same as that of Reiser with the difference that Reiser has the least internal fragmentation. Reiser with -notail outperforms both with comparable but still less internal fragmentation. (corresponding CPU usage for the 4 GB case)
  
  
  

  Verification of Gauge Measurements

  Test System

  To verify some of the above shown gauge results I have setup a few different measurements on a slightly different test system (in fact only the processor's speed has changed)

  • Hardware: AMD Duron 650 Mhz, 128 MB, 40 GB EIDE-harddisk for the system with the tests taken on
    • Adaptec AHA-2940U2/W host adapter
    • 9 GB IBM DNES-309170W SCSI-harddisk
  • Software: SuSE 7.2 (gcc 2.95-3) kernel 2.4.5 with the following official patches for the filesystem that were not shipped with it:
    • XFS version 1.0 (06112001) for 2.4.5
    • JFS version 1.0 for 2.4.5
    • Ext3 version 0.8 for 2.4.5
  which in contrast to above is running completely untouched (in runlevel 3 without any unneeded services).
  
  
  

  Verification of the 500 MB results

  The file size distribution is the same as above and looks as shown for the 550 MB case.
  
  For 100x50 directories the write performance in the 500 MB case (with corresponding cpu time) shows the same characteristics as in the first measurements above. For a better comparison of the old gauge measurement (marked with "nodel") and the new measurements (marked with ''gauge'') see the combined chart (corresponding combined cpu time).
  
  To get an idea how the write performance changes with the chosen directory structure I compared three different setups using a directory structure of 100x50 (corresponding cpu time) as above, 100x10 (corresponding cpu time) and 100x1 (corresponding cpu time). The different filesystems behave as following:
  • ReiserFS directory structure comparison (corresponding cpu time)
    ReiserFS writes fastest if it has the least number of directories (for 100x1).
  • XFS directory structure comparison (corresponding cpu time)
    XFS performs also best for the 100x1 case. It also does not show the sharp drop in that case. For the other cases it does show it as above which was the reason to verify the measurements as some people in the XFS mailing list did not believe in the outcome of my previous gauge tests.
  • JFS directory structure comparison (corresponding cpu time)
    JFS strongly depends on the directory structure and shows smooth behavior only for the 100x1 case.
  
  
  

  Verification of the 1 GB results

  To verify the idea that the write performance depends on the directory layout I did measurements for the 100x100, 100x50, 100x10 and 100x1 directory hierarchy. The file size distribution is the same as above and looks as shown for the 1 GB case. The 100x1 case is favored by all systems except for JFS where the picture is not clear.
  • Reiser 1GB directory structure comparison (corresponding cpu time)
  • Reiser notail 1GB directory structure comparison (corresponding cpu time)
  • XFS 1GB directory structure comparison (correspondingcpu time)
  • JFS 1GB directory structure comparison (corresponding cpu time)
  Note: This time the data was taken in a different way: Instead of running from 0 to 100 percent I measured from 0 to 25, from 25 to 50, from 50 to 75 and from 75 to 100 percent usage. It seems that the result depends on that, but I do not understand why this always results in a performance drop for the first measurement of the new cycle (eg. for the 25, 50 or 75 percent bin)!
  
  

  Verification of the 4 GB results

  The file size distribution is the same as above and looks as shown for the 4 GB case.
  
  For 100x50 directories the write performance in the 4 GB case (with corresponding cpu time) shows the same characteristics as above. Unfortunately I have not reproduced the same directory structure 100x100 yet, but I plan to do it.
  
  
  

  TODO

  • Use realistic eg. measured directory structures and file size distributions (done, see the agesystem3 section)
  • Do not always create but append (done, see the append tests)
  • Use fixed file sizes to see if there are changes (done, see the gauge performance section)
  • Do measurements with newer kernel and newer patches (done, see the gauge performance section)
  • Do gauge read measurements for different setups (done, see the gauge performance section)
  • Understand the performance degrade of the journaling filesystems compared to Ext2 which seems to be fairly constant (though slower) over the whole x-axis.