I think the layout of things might really be in the way of performance
here.

a) syncing of the FTREEDB in "/vicepa" occurs currently for every
create/remove.  Probably with new inode methods this will go away. 

The kernel however syncs the entire partition -- this could cost you
badly. 

b) same for the LOG and the data: are they RAW partitions, i.e. hdb7 & 8
(for example) or FILES in these partitions. 

The log is ideally on a disk by itself since it is written sequentially
and this eliminates the seeks.   When transactions occur, the log is
synced.

Just out of curiosity, I'd like you to move the FTREEDB to another disk
(you'll have to put a symlink in place of its currentl location) and try
once more. 

Peter


On Tue, 10 Feb 1998, Steven N. Hirsch wrote:

> 
> 
> On Tue, 10 Feb 1998, Peter J. Braam wrote:
> 
> > Steve,
> > 
> > I'd still like to know how your /vicepa (for files), RVM DATA and LOG are
> > organised, since it can dramatically impact performance.
> > 
> > Peter
> 
> Peter,
> 
> In my system, /vicepa is actually /usr/src/vicepa.  /usr/src is a faster
> and larger hard drive, so it seemed more appropriate to put it there.  The
> drive itself is an IBM DFHS 4-GB Wide-SCSI unit, and one of the fastest
> disks I own.
> 
> RVM data is 12M in length, and placed on its own partition at the end of
> the IBM DFHS drive.  Log is 2M, also with its own partition immediately
> following the data partition.  Long-term average bandwidth on that drive
> (though the ext2 filesystem) is 5.2MB/sec. write and 7.2MB/sec. read - it
> smokes. 
> 
> My original setup had RVM data and log as files on the root drive, but
> speed is about the same in the current case.  Granted this doesn't make
> sense..
> 
> The benchmark results from iozone and Bonnie indicate ~400-600B/sec.
> bandwidth.  On file copying, it seems as if an enormous amount of churning
> is taking place.
> 
> Steve
> 
>