Path: utzoo!attcan!uunet!modcomp!geoff From: geoff@modcomp.UUCP Newsgroups: comp.realtime Subject: Re: real-time multicomputer systems Message-ID: <110400004@modcomp> Date: 6 Jun 90 19:55:00 GMT References: <404@nominil.lonestar.org> Lines: 60 Nf-ID: #R:nominil.lonestar.org:404:modcomp:110400004:000:3533 Nf-From: modcomp.UUCP!geoff Jun 6 15:55:00 1990 The discussion on contiguous disk files has concentrated on the elimination of seek times as being the major benefit. Another important benefit is the ability to pass more data in each disk i/o operation, reducing the total number of such operations. An additional benefit on reads is that modern disks often have considerable amounts of RAM and autonomously read ahead into this local cache. Contiguous files benefit from this feature. Here at Modcomp we have produced REAL/IX, a Unix System V based realtime operating system which I'll use as the basis for discussion. In addition to the standard System V file system, we have yet another fast file system. The allocater on the latter is designed to place file blocks contiguously wherever possible, making a "mostly contiguous file system". Files are normally accessed via the buffer cache. If a sequential read is detected, REAL/IX takes advantage of any contiguity by reading several blocks from disk into several buffers in the cache in a single I/O operation. Similarly, writes to contiguous disk blocks can be combined into a single operation. We find that for applications that make intensive use of sequential I/O to large files, throughput can be approximately tripled. In a development environment, the number of disk I/O operations is reduced by, roughly, a factor of 30%. Your mileage may vary. The trade off for using mostly contiguous files is the increased overhead of the block allocater. For very small files or for temporary files that will never touch the disk the standard allocater will be marginally better. The use of larger block sizes is an alternative method of reducing the number of I/O operations, involving a different set of trade offs. There is nothing revolutionary about these techniques, variants of which have been adopted by some other vendors. Their absence from the Unix porting base has lead to their absence from most Unix implementations, leading to the urban myth that Unix filesystems have intrinsically poor performance. Explicitly preallocated contiguous disk blocks are the current empirical method for obtaining maximum disk I/O throughput. If disk and controller are used for no other purpose, guaranteed and small access times result (with the caveat that file accesses cannot be made via the buffer cache). REAL/IX also provides prioritisation of disk I/O requests from realtime processes to allow shared use while providing access time guarantees. The use of contiguous files with asynchronous I/O operations is a natural combination when attempting to obtain the maximum possible throughput. Here we find another benefit of contiguity, simpler asynchronous file I/O. As has been noted, there are problems with explicitly preallocated contiguous files, particularly what to do when you come to the end. There is probably no single right way to deal with this, so we allow the user to specify what action to take. Finally, I'd like to follow up on Steve Brosky's interesting figures for the Harris Night Hawk system. I appreciated the care used in explaining just what the numbers referred to. One of the benefits of the Posix 1003.4 standard, when it is eventually finished, should be that a set of common performance metrics will come into use, allowing users to directly compare systems. Geoff Hall uunet!modcomp!geoff Modcomp modcomp!geoffi@uunet.UU.NET 1650 West McNab Rd Ft Lauderdale, FL 33340