Ric Wheeler @ EMC Corp.
file system.
File system may have write barrier bug, which will not protect synchronous write from other write.
If a file system have write barrier not protecting synchronous write, the number of synchronous (single threaded) operations/sec will exceed the calculated number of synchronous operations/sec of the underlying drive.
An example in our case is that we use fairly slow IDE disks that should support around 50-60 synch ops/sec (you can figure this out based on the drive specifications). Using fs_mark, we saw a greater than expected (~100) files/sec written to a file system.
For example, one data sheet for the new Maxtor S-ATA drives, shows an average latency of 4.17 ms and an average seek time of 9.0 ms. In total, that gives us 13.17 ms per operation.
Using this rough set of numbers, you should see a average of 1000 / 13.17 = 75.93 sync operations/sec. When running a single threaded fs_mark test, any test that exceeds 76 files/sec have chance of suspect.
There is some small chance that you will exceed this, but overall, writing a file to disk typically involves several synchronous operations. In practice using a slower drive, I typically see about 60% of the equivalent number of files/sec.
More importantly, I would like to see how different file systems perform across their life span (from 0% used up to 100%) with various sizes and both single and multithreaded. You can also run the test against multiple drives by using
"-d /my/disk/mount_point1 -d /my/disk/mount_point2 ...".
I think that it would be very interesting to get a set of gnuplot results (say in Postscript) for different test cases.
fs_mark 3.2 is now available.
Result from Ric Wheeler@ EMC Corp. Oct. 2004.
| version | date | Author |
|---|---|---|
| log | ||
| 3.2 | 2005/10/25 (JST) | Ric Wheeler@EMC Corp. |
FixI was not recording all of the time spent doing the write() system call for files larger than the 20k write size. This would give you an artificially high number from fs_mark for files above this (not by much for modest file sizes, but this could definitely impact really big file rates). New ChangesAn additional change I made is to measure the file/sec rate in a more obvious way than I used to. In the previous version, the rate was time spent in open/write/fsync/sync/close, etc divided by the number of files written. This ignores the overhead of the code itself. The current version wraps the file writing loop with a timer and does the more obvious "wall clock" time divided by files written computation. To help give an idea of time spent by my code in non-file writing mode, I use the time measured in system calls and wall clock time to compute the "app overhead" in microseconds. This is meant to help answer the variability questions that Jon and others have raised (i.e., am I not getting scheduled or is it the IO subsystem). |
||
| 3.1 | 2005/09/27 (JST) | Ric Wheeler@EMC Corp. |
| fs_mark version 3.1 removed some non-write related tests and added a default quiet mode which logs only the basic files/sec information. To get detailed information, users can use the new "-v" flag to log the minimum, average and maximum system call times during the test run. In addition, please see the README file for information on the new support for bulk synchronization techniques. | ||
| 3.0 | 2005/08/29 (JST) | Ric Wheeler@EMC Corp. |
| 1.30 | 2004/09/25 (JST) | Ric Wheeler@EMC Corp. |