Chris Mason wrote:
> On Wednesday, May 09, 2001 04:54:00 AM -0700 Hans Reiser
> <[EMAIL PROTECTED]> wrote:
>
> > Ragnar Kjørstad wrote:
> > >> On Wed, May 09, 2001 at 08:26:23PM +0200, Philippe Gramoulle wrote:
> >> > Just wanted to let you know my benchmarks on a dual 650Mhz, SCSI disks
> >> > and 2.4.4 + 1.5 Go RAM
> >> > >> > mbox file of 57,7 Mo exploded into 17431 mails.
> >> > >> > /usr/bin/time mutt -f /var/spool/mail/toor -e 'set quit="yes"; exec
> >> > quit' gives on an ext2 fs : 2 minutes and 03 seconds:
> >> > >> > on Reiserfs it gave :
> >> > >> > 56 seconds :o) ( Mail was in the *cur*. Nothing in cache as the machine
> >> > was just rebooted before the test)
> >> >> It seems that reiserfs is faster as long as the data fits in the cache
> >> _or_ the files are not stat'ed - but if the stat-data has to be read
> >> from disk, ext2 wins.
> > > well then, that requires plan A to fix, reiser4.....
> >
> plan A might help, but I doubt it. Any operation on the file ends up
> logging the inode, which ends up searching for the inode in the tree all
> the time. I'd love to make some stats on how often searches are done for
> stat data, and come up with caches to lower that number.
you are saying it is atime that kills our performance? Do you remember our long ago
discussion of making atime dirties of leaves not be logged? Any reason other than
lack of time for not doing that?
>
>
> plan A puts the stat data in with the directory item, which would make a
> stat right after a lookup faster. But, the larger issue is the number of
> times we search for the stat data during each operation.
>
> This is the whole reason noatime is so much faster.
>
> -chris
