Desktop Filesystem Benchmarks in 2.6.3

[Chris Mason]

On Wed, 2004-03-03 at 18:41, Johannes Stezenbach wrote:
> Peter Nelson wrote:
> > Hans Reiser wrote:
> > 
> > >Are you sure your benchmark is large enough to not fit into memory, 
> > >particularly the first stages of it?  It looks like not.  reiser4 is 
> > >much faster on tasks like untarring enough files to not fit into ram, 
> > >but (despite your words) your results seem to show us as slower unless 
> > >I misread them....
> > 
> > I'm pretty sure most of the benchmarking I am doing fits into ram, 
> > particularly because my system has 1GB of it, but I see this as 
> > realistic.  When I download a bunch of debs (or rpms or the kernel) I'm 
> > probably going to install them directly with them still in the file 
> > cache.  Same with rebuilding the kernel after working on it.
> 
> OK, that test is not very interesting for the FS gurus because it
> doesn't stress the disk enough.
> 
> Anyway, I have some related questions concerning disk/fs performance:
> 
> o I see you are using and IDE disk with a large (8MB) write cache.
> 
>   My understanding is that enabling write cache is a risky
>   thing for journaled file systems, so for a fair comparison you
>   would have to enable the write cache for ext2 and disable it
>   for all journaled file systems.
> 
> It would be nice if someone with more profound knowledge could comment
> on this, but my understanding of the problem is:
> 
Jens just sent me an updated version of his IDE barrier code, and I'm
adding support for reiserfs and ext3 to it this weekend.  It's fairly
trivial to add support for each FS, I just don't know the critical
sections of the others as well.

The SUSE 2.4 kernels have had various forms of the patch, it took us a
while to get things right.  It does impact performance slightly, since
we are forcing cache flushes that otherwise would not have been done.

The common workloads don't slow down with the patch, fsync heavy
workloads typically lose around 10%.

-chris