Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!cs.umn.edu!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott
From: scott@nic.gac.edu (Scott Hess)
Newsgroups: comp.sys.next
Subject: Re: Small executables (was Re: 16mb minimum for next machines)
Message-ID: <SCOTT.91May5174536@nic.gac.edu>
Date: 5 May 91 22:45:36 GMT
Article-I.D.: nic.SCOTT.91May5174536
References: <1991May2.142103.6047@potomac.ads.com> <650@rosie.NeXT.COM><aj7G3.u=1@cs.psu.edu>
Organization: Gustavus Adolphus College
Lines: 60
Nntp-Posting-Host: nic.gac.edu
In-reply-to: melling@cs.psu.edu's message of 4 May 91 11:13:22 GMTLines: 60

In article <aj7G3.u=1@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes:
   In article <N67786.91May4013238@lehtori.cc.tut.fi> n67786@cc.tut.fi (Tero Nieminen) writes:
      In article <650@rosie.NeXT.COM> sstreep@elvis (Sam Streeper) writes:

	 No file on disk will ever be smaller than the sector (or perhaps
	 cluster) size, even if it has very few "meaningful" bytes.

      Time for you to recheck the BSD fast file system internals, cause your
      statement does not hold.

   Could you explain?  Wasn't he talking about internal fragmentation?
   Inquiring minds want to know.

You asked for it!

Say that the cluster size is 8192 and the sector size is 512 (these
are both the default for NeXT-shipped NeXTs I think - though they
say they recommend 1024-byte sectors, I've yet to see one from
them that says that :-).  Then, the basic unit of allocation
will be 8192, the cluster size.

_But_ this means that, on average, we'd lose 4096 bytes per file.
Since Unix has alot of files, this is obviously a problem.  The
simple solution is to make the cluster size smaller (say, 1024),
so that there is less waste.  The down side is that then you need
more space for the block listings (that indicate the location of
each block in the file), and the file system is slower.

So, what was done for FFS was a comprimise.  The block size can
still be large, but they introduced the concept of a fragment,
which would be some amount of space than a block in size, but
an integral number of sectors.  This could be used to represent
the trailing partial block of a file.  Also, multiple fragments
could be placed in a single block, so the wasted space is no
longer.

In the case of a NeXT, you'll probably have a block size of 8192,
and a sector size of 512, so fragments should be n*512 in size,
where n goes from 1 to 15.  Otherwise, in a 1024 byte sectored
system, it will be n*1024, where n is 1-7.

This all is limited to use on short files, I believe.  Just implementing
it for files <block size is generally good enough, because those
are the most wasteful files (in relative terms).  Also, many files
on the NeXT (executables come to mind) are a multiple of 8192 in size
because Mach likes to see integrally-paged files (pagesize is 8192).
But, data files should get the right treatment . . .

Flame away.  This might be all wrong, but I suspect not - maybe some
of the details are slightly off.  I got most of my info from
"Design and Implementation of 4.3BSD Unix", which is a good
book to have on your coffee table . . .

Later,
--
scott hess                      scott@gac.edu
Independent NeXT Developer	GAC Undergrad
<I still speak for nobody>
"Simply press Control-right-Shift while click-dragging the mouse . . ."
"I smoke the nose Lucifer . . . Banana, banana."