Disk benchmark (long)

[Bruce Adler]

In article <1990Oct13.032355.3176 at jdyx.UUCP> shawn at jdyx.UUCP (Shawn Hayes) writes:
>   I suspect that the two updates required in Unix explain why OS/2 can
>give a performance of up 3 times what AIX 1.2 shows.  If anyone knows of a
>method of improving file performance or of a Unix that gives increased file
>performance over AIX please speak up.  I'd really rather work on a Unix 
>system than OS/2 but disk performance is critical for our application.

I know zip about os/2 so forgive me if these questions sound stupid.  

It sounds like os/2 merely implements buffer cache write through but 
unix implements true synchronous file updates.  If you're appending to a 
file does os/2 really update the directory entry after every block 
write?  

On os/2 if you crash your system before closing the file do you still 
have all of your data (except perhaps the last block) intact after you 
reboot (including the proper timestamps on the directory entries)?  

If not, then the os/2 scheme is only usable when doing updates in place 
(i.e.  you have to pre-allocate the whole file). (This doesn't seem
like a "fair" comparison to unix's robust file system with synchronous
writes.)

If you're dealing with pre-allocated and initialized database files, 
then on unix you should put your database in a separate partition and 
use the raw-disk interface.  On my machine reading the raw disk (I would 
have tested writing but I don't have an empty partition) via:

	dd if=/dev/rdsk/0s4 of=/dev/null bs=1k count=560
        
takes less than 3 seconds (note: I'm running ISC Unix not AIX).  But to 
use the raw disk interface efficiently you have to do your own buffer 
cache management (be sure to plock() your process).  Now put this all in 
a separate process add crash recovery, shared memory, record locking, 
mutual exclusion, threads and/or an RPC mechanism and I believe this is 
what most commercial, multi-user, high performance database systems do 
(or should be doing) on unix.  

If you're doing something that's time critical or so large and complex 
that you're worried about performance on a 33mhz 386 then it's a waste 
to try to implement your own database system.  Buy a real database 
system.  

If all you're really doing is some flat file record manipulation, or 
what we used to call "data-entry" then you may as well use dos rather 
than os/2 or unix.  So what is it you're really trying to do other than 
avoid having to work on os/2?  :-) 

-- 
bruce at segue.com, ism.isc.com!segue!bruce, aero.org!segue!bruce