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
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, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On Wed Dec 7 16:55:38 EST 2005, [EMAIL PROTECTED] wrote:
I don't have this problem on Inferno because my file system
cache (which delegates to venti) doesn't have this bug.
I didn't realize that anyone would write a cache that breaks
when it fills. I'm not touching fossil.
brucee
How I
cache.c:698: * BUG: if the disk is full, should we flush some of it to Venti?
Should we? It's still not clear to me. There are fossil console
commands you could have typed to free up a little space
and run an archive to venti.
To find your old vac scores, see /sys/src/cmd/venti/dumpvacroots.
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
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 [EMAIL PROTECTED] wrote:
of course. or don't call it
