From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200008010604.CAA09425@cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Installing the updates
From: "Russ Cox" <rsc@plan9.bell-labs.com>
Date: Tue,  1 Aug 2000 02:04:45 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: f03cd856-eac8-11e9-9e20-41e7f4b1d025

[didn't mean to send that first one -- misclicked]

	A user could have the distribution source on a CDROM and view it via a
	cache file
	server. This would store only the files that have changed - using copy
	on write.
	I suspose this could be extended to storing only the blocks that have
	changed, or
	even file diff(1) output, or wrap(8) file even...
	
	I'am not sure if this is interesting or hedious :-)

I think it's interesting, at least until you
start talking about saving individual blocks
or diff output, at which point it gets complicated
enough to perhaps qualify as hideous.
Especially since with the exception of log files
and the fortune database, files tend to be rewritten
completely when they change.

I've thought about writing such a thing a number
of times, but been scared away both by not having
a name for it and by the complexity of the state
machine you'd need to use only a constant number of
processes.

I've since come up with a name -- stitch -- and
I think that you can use libthread to great advantage
to manage the complexity, but I haven't tried it.

If you had such a thing, you could try out
new wrap updates by doing

	gunzip < /tmp/new.9gz >/tmp/new.9
	archfs /tmp/new.9
	stitch -b /tmp/new.9 /

which would be neat.

Russ