Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!usc!snorkelwacker!apple!sun-barr!decwrl!sgi!shinobu!odin!sam!pj
From: pj@sam.sgi.com (Paul Jackson)
Newsgroups: comp.sys.sgi
Subject: Re: Building files from other files
Message-ID: <4094@odin.SGI.COM>
Date: 14 Feb 90 04:33:43 GMT
References: <9002121455.aa22106@SMOKE.BRL.MIL>
Sender: news@odin.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 37

In article <9002121455.aa22106@SMOKE.BRL.MIL> JORDAN@gmr.COM writes:
	(to paraphrase)

| We work in a real time environment, and have noticed something strange
| in a particular "driving" loop.
| 	a.c				# a.c has OK performance
| 	cp a.c a.copy			# a.copy has OK performance
| 	cat b.c >> a.copy		# now a.copy has slow performance
| 	"delete b.c from a.copy"	# a.copy still has slow performance

How did you delete b.c from a.copy?  Unix has no way to shorten a
file while it is in place on the disk.  I presume you deleted b.c
by using an editor (such as vi).  All editors work by making
copies of the file, applying the changes and linking or copying
the result back.  This reallocates the disk space used for that
file.

I would guess perhaps that a.copy, after b.c was added,
spanned multiple extents.  And I would also guess that
after "deleting b.c ...", a.copy still took multiple extents.
That it still took multiple extents is a little surprising,
as our (yes - I work for SGI) Extent-based File System does
a pretty good job of keeping files together that are written
in one open-write-write-...-close sequence.  But it certainly
is possible.

To further improve this guess, one would need to know the sizes
of the files, and how much space was free on the disk partition
after each of the above steps.  Allocating contiguous extents is
harder on a nearly full disk.

Why don't you try calling our Geometry Hotline (800) 345-0222.
These folks do a real fine job of handling such questions.
I use them myself.

				Thanks, take care ...
				Paul Jackson (pj@asd.sgi.com), x1373