Revision history

• Revision history
• 1. Base kernel level : on 2.6.10 kernel
• 2. Interested Filesystem/mount options:
  • 2.1 Base ext3 filesystem (reservation default is on in 2.6.10) :
  • 2.2 Evaluate if there is any regression on reservation changes
  • 2.3 For extents, delayed allocation, multiblock allocation
  • 2.4 For comparing with other filesystem
• 3 Functionality test
  • 3.1. Scalability test
• 4 Performance test
  • 4.1 FSB
  • 4.2 tiobench -- good tests for sequantial/random read/write
  • 4.3 dbench -- heavy meta data workload
  • 4.4 dd tests -- simple quick tests for sequential write/read
  • 4.5 big file create/delete tests -- a simple scripts will do(need code up)
  • 4.6 bonnie ++ --- this will create large and small files
  • 4.7 iozone
  • 4.8 postmark
  • 4.9 AIM
  • 4.10 Lmbench --- the filesystem microbenchmarks
  • 4.11 sysbench
  • 4.12 ssh buildbenchmark/or kernel build benchmark
  • 4.13 Karl Swartz's Netnews benchmark [2].
  • 4.14 Pgmeter
  • 4.15 Filemark
  • 4.16 Samba 4 --- to test the EA in inode patch --- we need to talk to Tridge about this
  • 4.17 sqlbench
  • 4.18 mongo
  • 4.19 Other tests
• 5 We would like to run all above tests on all patches. We can do it sometimes, but some tests are probably more useful to some patches :
  • 5.1 For extents:
  • 5.2 For the EA-in-inode patch,
  • 5.3 For large cpu scalability
  • 5.4 For reservation patch:
  • 5.5 For multi blocks allocation patch(es)
  • 5.6 For delayed allocation patch(es)
  • 5.7 For 64 bit support patches

1. Base kernel level : on 2.6.10 kernel

2. Interested Filesystem/mount options:

3 Functionality test

• LTP filesystem tests
• fsx tests

3.1. Scalability test

4 Performance test

• Interested tests : sequential/random read/write; file create/remove; directory operations; heavy metadata workload.
• Interested data : throughput, cpu and iostat, profiling, lockmeter

4.1 FSB

This is the test LTC performance team used to evaluate filesystem performance. It is said could be configured to run any combination of sequential/random/read/write/heavy metadata. I would suggest we set this up as well : 

• Interested tests: sequential/random read/write; file create/remove; directory operations; heavy metadata workload.
• Interested data: throughput, cpu and iostat, profiling, lockmeter

4.2 tiobench -- good tests for sequantial/random read/write

• Interested tests: sequential/random read/write;
• Interested data: throughput, cpu, iostat, profiling, lockmeter

4.3 dbench -- heavy meta data workload

• Interested tests: sequential/random read/write;
• Interested data: throughput, cpu, iostat, profiling, lockmeter

4.4 dd tests -- simple quick tests for sequential write/read

• Interested tests: sequential read/write;
• Interested data: time(real/sys) iostat

4.5 big file create/delete tests -- a simple scripts will do(need code up)

• Interested data: time(real/sys) iostat

4.6 bonnie ++ --- this will create large and small files

4.7 iozone

4.8 postmark

4.9 AIM

4.10 Lmbench --- the filesystem microbenchmarks

4.11 sysbench

4.12 ssh buildbenchmark/or kernel build benchmark

• As Margo Seltzer's "Journaling versus Soft Updates" paper [1] points out, the Modified Andrew Benchmark (like the original Andrew Benchmark) is now too small to stress modern filessystems. So they have proposed the ssh buildbenchmark, which measures the time to (a) unpack, (b) configure, and (c) build ssh version 1.2.26. Alternatively, we can also do the famous "kernel build" benchmark instead.

4.13 Karl Swartz's Netnews benchmark [2].

• This measures primarily lots of metadata operations, and since there is very little locality of reference, causes a lot of seeks across the disk.

4.14 Pgmeter

• Like Bonnie (but not as well known in the open source community) measures I/O throughput.

4.15 Filemark

• Described in Ray Bryant, Ruth Forester, and John Hawkes' Filesystem Performance and Scalability in Linux 2.4.17

4.16 Samba 4 --- to test the EA in inode patch --- we need to talk to Tridge about this

4.17 sqlbench

• Interesting test to evaluate performances on some real use.
  

4.18 mongo

• Comes from Reiser. To compare results with Reiser FS for which it has been done.

4.19 Other tests

• Interesting ones are those done as real use cases :
• compilation,
• files operations (write, rm...).

• Not interesting ones :
• kernbench : not appropriate for FS testing because files are memory cached.

5 We would like to run all above tests on all patches. We can do it sometimes, but some tests are probably more useful to some patches :

5.1 For extents:

5.2 For the EA-in-inode patch,

5.3 For large cpu scalability

5.4 For reservation patch:

5.5 For multi blocks allocation patch(es)

5.6 For delayed allocation patch(es)

5.7 For 64 bit support patches