Re: fs_mark benchmark - update

[Ric Wheeler <ric@emc.com>]

I use it to benchmark (mostly) synchronous file writing.

For example, a typical run might be to completely fill a file system 
with 50k files using the default (write one file, fsync one file) method 
and then compare that run to one which uses a varying number of 
concurrent threads.

Data journal mode is slightly faster for small files, but is twice as 
slow for large files (as expected).

We have observed the best results in 2.6 reiserfs3 when running 4-8 
threads per disk, using multiple subdirectories.  In 2.4, using a single 
subdirectory on reiser was better than using multiple subdirectories.

The validation of the write barrier case test is a simple one - if you 
write single threaded, then a properly configured file system with write 
barrier enabled should be some reasonable match to the speed of the 
disk.  For us, that is typically around 40 50k files/sec with S-ATA 
drives or P-ATA drives.

It is also interesting to compare reiserfs vs ext3 when writing single 
threaded across the life span of a file system - reiserfs typically 
beats ext3 for most cases, but ext3 eventually catches up as the 
percentage used grows.

I hope to rerun on reiserfs4 and the new ext3 in the next few weeks,

Regards,

Ric


Ming Zhang wrote:

>have a quick check on u site and it is interesting.
>
>but this is more like a validation tool instead of performance benchmark
>tool. or your code will report how many sync IOPS it gets and then we
>validate with our own HW spec.
>
>i should ask this after running the code i guess. :) but eager to know
>answer.
>
>ming
>
>
>
>  
>
>