Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!ncar!ico!rcd From: rcd@ico.isc.com (Dick Dunn) Newsgroups: comp.unix.sysv386 Subject: Re: Proper UNIX FS, ISC disk performance Summary: inode location Message-ID: <1990Oct17.035831.11891@ico.isc.com> Date: 17 Oct 90 03:58:31 GMT References: <1990Oct9.015948.551@jdyx.UUCP> <1990Oct12.231159.23105@ico.isc.com> <102@raysnec.UUCP> Distribution: usa Organization: Interactive Systems Corporation, Boulder, CO Lines: 43 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.