Re: [9fans] fossil woe

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

so it should be made clear that fossil is not appropriate for
large files or file system traffic.  if i wish to create a 5G file
and fossil is 10G can i?  well it depends on what has happened
since the last snap.

brucee

On 12/7/05, Russ Cox <rsc@swtch.com> wrote:
> > of course. or don't call it a cache but "something that may
> > fill up and screw you over".  the machine was far too hosed
> > to connect to fscons and in any case telling a user "if you
> > do too much stuff you will have to call me to fix fossil" is
> > not aacceptable.
>
> I'm not claiming, under any circumstances, that fossil
> becoming unusable is acceptable.  However, the solution
> is not as simple as "just write the blocks to venti".
> First, writing blocks to venti requires some knowledge
> of the rest of the file server state, and you can't always
> write any block to venti.  Second, some people don't even
> use venti and they can fill their fossils too.
>
> There are plenty of subtle things going on in fossil that make
> it much harder to handle the disk being full than in a conventional
> file system.
>
> 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.
>
> If someone wants to work on making this happen, I would be
> happy to provide further details.
>
> Russ
>