From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <775b8d190512071312n1466dae3ke29f2d19ddfc7cc1@mail.gmail.com>
Date: Thu,  8 Dec 2005 08:12:12 +1100
From: Bruce Ellis <bruce.ellis@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] fossil woe
In-Reply-To: <44db37f075e341c3264601a498c2b4b7@vitanuova.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <ee9e417a0512061541v5a2a036dud3e32abc7363e74c@mail.gmail.com>
	<44db37f075e341c3264601a498c2b4b7@vitanuova.com>
Topicbox-Message-UUID: be07fdae-ead0-11e9-9d60-3106f5b1d025

this misses the point.  a cache must cope with an "I'm full"
condition otherwise it can and will fail.  i'd much rather a
long delay on a file-op when fossil does a "I'm nearly full"
snap than a few days to rescue a smashed system.

brucee

On 12/8/05, rog@vitanuova.com <rog@vitanuova.com> wrote:
> > Fossil needs some notion of being close to full, at which point
> > its behavior would change.  Automatic snapshots would stop,
> > as would mtime updates and any other source of automatic
> > dirtying of blocks.  There should be a few blocks reserved for
> > snapshots taken in response to manual console commands.
> > Then when fossil fills, you can remove recently written data
> > (if some runaway program has filled the disk) or connect to
> > the console and delete old snapshots or take an archival
> > snapshot.
>
> this seems fine, but... it still seems somewhat arduous when all
> one really wants to do is copy a load of data to venti.
>
> one idea:
>
> why not make it possible to directly insert vac archives into
> a fossil filesystem?
>
> e.g. with a new fossilcons command:
>
>        createvac path score uid gid perm
>
> fossil could remap the (possibly spurious) usernames in the
> vac archive, for instance by mapping all user and group ids to
> the given uid and gid.
>
> then a large quantity of new data could be "vac"ed directly
> onto venti, and then made available within fossil.
>
> in combination with the "vac" console command, this could make
> other previously hard things straightforward; for example replicating
> or moving huge directories from place to place without
> copying all the data.
>
> would this be very hard within the current fossil structure?
>
>