Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!ka3ovk!raysnec!shwake
From: shwake@raysnec.UUCP (Ray Shwake)
Newsgroups: comp.unix.sysv386
Subject: Proper UNIX FS, ISC disk performance <was: Disk benchmark (long)>
Message-ID: <102@raysnec.UUCP>
Date: 16 Oct 90 03:09:22 GMT
References: <1990Oct9.015948.551@jdyx.UUCP> <1990Oct12.231159.23105@ico.isc.com> <1990Oct13.032355.3176@jdyx.UUCP>
Distribution: usa
Organization: IRS/CI - Technical Solutions Branch
Lines: 23

shawn@jdyx.UUCP (Shawn Hayes) writes:

>What I would like to find is either
>a version of UNIX that has better disk performance capabilities( perhaps by
>putting the inode and the file data at the same point on the disk) or another
>way of accessing/updating the data that avoids the inode update penalty. 

	Ah, but then it wouldn't be a proper UNIX filesystem. In the latter,
the inodes go in the superblock, while the data goes in the data block.

>   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've been quite impressed with Interactive's latest UNIX, which
implements a Fast Filesystem (unlike the Berkeley version, ISC's *is*
System V compatible). The 'bench' program published last year in UnixWorld
tests out on my system at twice as fast as SCO UNIX; this probably results
from the minimal fragmentation under real world conditions using ISC. 
(This result was confirmed using 'fsanalyze'. SCO die-hards, kindly
redirect flames to /dev/null.)