Re: [9fans] fossil woe

[Bruce Ellis <bruce.ellis@gmail.com>]

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?
>
>