Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zds-ux!gerry
From: gerry@zds-ux.UUCP (Gerry Gleason)
Newsgroups: comp.unix.i386
Subject: Re: mkfs gap option
Message-ID: <291@zds-ux.UUCP>
Date: 1 May 90 19:49:27 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: gerry@zds-ux.UUCP (Gerry Gleason)
Organization: Zenith Data Systems
Lines: 17

In article <PCG.90Apr30215541@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>In article <511632@nstar.UUCP> larry@nstar.UUCP (Larry Snyder) writes:
>   I assume that this 6-8 sectors is based on operating systems which
>   don't have (or are using) a fast file system..

>Not really. The so called "fast file systems" work by *keeping* the free
>list sorted by block location (usually with a bitmap), not by block free
>time like the V7/SysV one.

I think you have missed the real point of FFS.  By keeping the free list
as a bit array ordered by disk location, you can allocate groups of
blocks at a time in contiguous locations.  The big win is then in reading
sequentially, multiple blocks of a file can be read with a single read
operation (of course the same can apply to writes).  Due to this behavior,
the gap variable becomes almost if not completely meaningless.

Gerry Gleason