Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!sol.ctr.columbia.edu!emory!jdyx!shawn
From: shawn@jdyx.UUCP (Shawn Hayes)
Newsgroups: comp.unix.sysv386
Subject: Re: Disk benchmark (long)
Message-ID: <1990Oct15.091904.5439@jdyx.UUCP>
Date: 15 Oct 90 09:19:04 GMT
References: <1990Oct9.015948.551@jdyx.UUCP> <1990Oct12.231159.23105@ico.isc.com> <1990Oct13.032355.3176@jdyx.UUCP> <4190@segue.segue.com>
Distribution: usa
Organization: JDyx Enterprises (Atlanta GA)
Lines: 48



     Well, what we're trying to do is essentially what those commercial 
multi-user high performance database systems do(i.e. we will have multiple  
prgrams accessing the database and it is critical for a low-end(386) system
to write directly to the disk.  As far as pre-allocation goes, that's probably
the way we would do it.  We would have pre-allocated all of the files that
are needed.
    I've tried modifying the benchmark to write/read from the raw-disk      
interface, but I had some problems with it.  I kept getting phys-io errors
in my tests.  If you've got a sample of code that handles raw-disk io I'd be
intersted in seeing it.  Maybe I can figure out what went wrong in my test 
of the raw-disk interface.                 

I'm also going to include my response to Dick Dunn which will help answer a
few questions about what is needed.



 

 
 
   I'm sorry about leaving everyone in the dark about this benchmark. 
I've been working on this off and on for the last six months so I start to
assume everyone understands what's going on. :>   
 
    What my company is looking at doing is making a system that is
portable to at least variations in the Unix OS, if not other operating
systems.  One  portion of this system is a database that will probably
consist of multiple files with multiple keys that must be read/updated by
multiple programs or by  a single program that acts as the database
manager.  
 
   In either case there is another computer that sends the data to us.  
Before the system can acknowledge the other computer the tranasction MUST
be posted to disk, otherwise our system and the other one would get out of
sync during a power failure.  For that reason the SYNC parameter is
needed.
 
   Now, some of you are thinking why not use a UPS system and the NOSYNC 
parameter.  Well, that will work for a larger system, but our marketing
people want us to be able to sell this system to anyone so for small
systems a UPS is out of the question.  That means that whatever operating
system we use must support a write-through cache. 
 
 
Shawn Hayes