shwake@raysnec.UUCP (Ray Shwake) (10/16/90)
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.)
shawn@jdyx.UUCP (Shawn Hayes) (10/17/90)
First, I thought there was no such thing as a 'proper' Unix filesystem.
All of them are replaceable, correct? The only thing that you might say is
'proper' is that the filesystem is the same as the BSD FFS or the AT&T
filesystem.
Second, did you run the benchmark I sent on your system? I'd be
interested in knowing what timings you get. I got an advertising blurb
from Interactive(Is that ISC?) that claims 300% improvement in disk speeds
over standard Unix, whatever that is. Is the filesystem selectable under
ISC, ie can I choose the FFS on one partition and the AT&T filesystem on
another?
Thanks for the info.
Shawnrcd@ico.isc.com (Dick Dunn) (10/17/90)
shwake@raysnec.UUCP (Ray Shwake) writes in response to some details of what Shawn Hayes is looking for, namely... > >...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. No, the inodes do not go in the superblock. The superblock contains the overall information for the file system. Traditionally, the inodes go in a separate area of the disk from the data--that is, there's a region of inode blocks and a region of data blocks. (Indirect blocks--those used for describing the file's allocation beyond the first handful of blocks which are listed in the inode--are taken out of the data block area.) It is possible to carve up the file system so that you've got a chunk of inodes, a chunk of data, another chunk of inodes, more data,... in an attempt to get the inodes closer to the data they describe. This is the organization used in the BSD fast file system; the inode-data chunks are called "cylinder groups." It's an open question whether the cylinder groups provide any real advan- tage. They may be more work than they're worth nowdays (with seek times being lower than in the past, but rotational latency still the same as long ago). > 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)... Yes, but one wouldn't expect a BSD file system to be Sys V compatible, since the BSD FFS predates System V! Also, of course, that's a market issue: ISC is in the Sys V market, and therefore spent some effort to stay SysV compatible on disk; BSD (meaning "those vendors who sell BSD-based systems" actually) isn't in the same market. In the case of both BSD and ISC ffs'es, the major gains are from allocation via bitmap and increasing the transfer size. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Never offend with style when you can offend with substance.