From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <3919c08679c5ef8fc6d801c62acfbc3b@quanstro.net>
To: weigelt@metux.de, 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Wed, 18 Jun 2008 16:32:47 -0400
In-Reply-To: <20080618193533.GA23589@nibiru.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Ideas for gc on venti
Topicbox-Message-UUID: c1a46774-ead3-11e9-9d60-3106f5b1d025

> Well, that's not yet any form of gc - just an smooth data moving
> from one volume to another - also good if you intend to take some
> disk offline in near future, w/o serious interruption.
> (The deprecated volume get emptier and emptier, and no new
> data is added.)

in the original venti paper, the problems associated with disk
management, redundancy and backup were ignored so they
could be handled seperately.

i think this is good design.  but i can't take credit for this
opinion.  i've had kernighan & plauger, elements of programming
style on my desk for a few days.  this is a book old enough to give
examples in pl/1 but i think it still gives advice which bears repeating.

one of the suggestions is that each function should hide something
important.

it makes sense for the storage managment function to present an
idealized block device while hiding details like disk replacement
and redundency.

now, if i could get all my own functions to live up to this standard....

- erik