Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ncar!boulder!pikes!udenva!isis!ico!dougp
From: dougp@ico.isc.com (Doug Pintar)
Newsgroups: comp.unix.i386
Subject: Re: mkfs gap option
Message-ID: <1990May2.164924.1644@ico.isc.com>
Date: 2 May 90 16:49:24 GMT
References: <511590@nstar.UUCP> <1990Apr19.025739.19180@nebulus.UUCP> <PCG.90Apr28151407@rupert.cs.aber.ac.uk> <511632@nstar.UUCP> <PCG.90Apr30215541@odin.cs.aber.ac.uk>
Reply-To: dougp@ico.ISC.COM (Doug Pintar)
Organization: Interactive Systems Corp., Boulder CO
Lines: 37

In article <PCG.90Apr30215541@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>
>I mean: when the file system is newly built, both the fast file system
>and the traditonal one have a free list sorted by location, and give
>essentially the same thruput (modulo other possible differences, like
>clustering of reads of writes).

Just to clear up any confusion, the 386/ix FFS DOES cluster reads, writes,
and allocations.  Reads of 16KB and more are common.  The standard filesystem
does separate reads for each block, 1KB at a time.  It is the interval
between THESE read requests that the FS gap is supposed to cover.

>This has *nothing* to do with the filesystem gap; this is a function of
>the interval spent by the OS between two disc operations (interrupt
>latency, time taken to empty/fill the controller's buffer, time taken to
>reissue the IO parameters). If the OS takes one millisecond between two
>IO transfers, the disc arm will have flown over typically one sector (of
>an MFM drive), and thus an interleave of 1:2 will be advisable.

This is actually a case for changing the HARDWARE interleave, not the FS
gap.  A 1KB block takes up 2 sectors on an AT-type machine, so the mkfs gap
won't help with the reading of the 2 (logically) consecutive sectors making
up each FS block.

>If you have a controller capable of hardware scatter gather, and an OS
>that can exploit it, then you don't need to interleave the free list, as
>consevutive sectors can be read without any interval for OS processing
>between them.

The standard AT controller (and clones) is a PIO device!  This kind of gives
you (admittedly CPU-intensive) scatter/gather that IS used by the HPDD.  Any
AT-compatible controller that supports 1:1 interleave has buffer memory on
board to handle any slack taken up by interrupt processing, data movement,
etc.  The Adaptec 1542 SCSI adapter supports hardware scatter/gather that
is also used by the HPDD.

Doug Pintar