Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site desint.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!trwrb!scgvaxd!wlbr!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.unix-wizards
Subject: Re:  What happened to the '-x' option of dcopy(1M) ???
Message-ID: <172@desint.UUCP>
Date: Sun, 28-Oct-84 15:19:24 EST
Article-I.D.: desint.172
Posted: Sun Oct 28 15:19:24 1984
Date-Received: Tue, 30-Oct-84 00:47:12 EST
References: <203@pyuxt.UUCP>
Organization: his home computer, Thousand Oaks, CA
Lines: 30

In article <203@pyuxt.UUCP> neal@pyuxt.UUCP (Neal Nuckolls) writes:

>What would be the PURPOSE of forcing executables to be
>stored contiguously?  This *could* reduce drive seeking if
>accesses against the particular filesystem tend to group
>in time with type (i.e. executable, non-executable).

But they *do* group in time with their type, at least on a swapping system.
A swapping system wants 100% of the executable at the same time;  this is
obviously time grouping.  (On virtual systems, this is not nearly so clear).

>In the case of mixed programs and their data on the same
>filesystem and assuming that data i/o exceeds initial
>text load the benefit from the '-x' option would be from
>having the *non-executables* (data files) contiguous.

Data files tend to be requested in much smaller chunks, and at much less
predictable time intervals.  Head motion caused by other processes (which
does not have to happen when you are loading an executable) will interfere
with any advantages gained from making them contiguous.

In general, any time you can predict the size of a disk read ahead of time
there is an advantage in making the blocks involved in that read contiguous.
On swapping systems, you always read in the whole executable.  This is not
true in general of data files on any system.
-- 

	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff