From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <597cc480771054920a8f1b67a2b634df@quanstro.net>
To: 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 19 Jun 2008 10:33:43 -0400
In-Reply-To: <834c6b3349485fa175573ec3dfb91b4d@9srv.net>
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: c32340c0-ead3-11e9-9d60-3106f5b1d025

> // combining functionality that is logically distinct is
> // generally called unmodular, and a layering violation
> // in this particular senerio.
>
> i agree with the principle, but i'm not sure it applies in this
> case. what's described (at least the part before any "garbage"
> collection is done) is really just arena management, not disk
> management. the arenas are all defined within venti, and
> nothing underneath really has any understanding of how (or
> if) they're being used. i don't think there's anything
> conceptually wrong with asking venti to be able to manage
> which arenas are "live" or not.

the case given was that a disk needed replacing.  i can run
your argument the other way and say that venti doesn't care
which disk goes where or how the storage itself is organized.
one should be able to replace a failed drive without involving
venti.

slightly off topic.  we use this to our advantage at coraid,
though we are not using venti.  our mail fs uses aoe storage.
there are not a lot of people expert in the adminstration of
our fs, but there are many people who can repair a degraded
raid or perform other storage administration.  this requires no
knowledge of the fs.

when you're on call 24/7/365 for fs problems, this is a
wonderful thing.

- erik