mkfs gap option

Doug Pintar dougp at ico.isc.com
Thu May 3 02:49:24 AEST 1990


In article <PCG.90Apr30215541 at odin.cs.aber.ac.uk> pcg at 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



More information about the Comp.unix.i386 mailing list