From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200303192009.h2JK9L804993@zamenhof.cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fossil: disk is full
In-reply-to: Your message of "Wed, 12 Mar 2003 11:43:22."
             <5f8e0c9e7b39e0e6086945e534c7cd64@vitanuova.com> 
References: <5f8e0c9e7b39e0e6086945e534c7cd64@vitanuova.com> 
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4987.1048104560.1@zamenhof.cs.utwente.nl>
Date: Wed, 19 Mar 2003 21:09:20 +0100
Topicbox-Message-UUID: 81b0b8aa-eacb-11e9-9e20-41e7f4b1d025

For the record (or the archives), I'd like to mention that for me
the numbers in the following (conservative?) script allow me to
copy > 20 Gb to fossil with a disk cache of 1 Gb and some 50Gb
of venti. The number are conservative in the sense that I tried
to stop mkext long enough for the snap -a to finish.
It seems I did not succeed in that, but at least it seems that
one 'snap -a' finishes before the next one is started.
In some 24 hours something like 12 Gb gets copied.

Different numbers in the script and/or different cache size
command line flags for fossil-open -c and for venti (see below)
might make it faster (doing more in parallel); for me right now
(after a runaway script that flooded fscns with 'snap -a' requests
and thus broke fossil) the main thing is that it gets the (copying)
job done.

 while () {
	date
    echo sleep 1800
    sleep 1800
	date
    echo stop mkext
    stop mkext |rc
	echo snap -a
	echo snap -a >> /srv/fscons
	date
    echo sleep 1800
    sleep 1800
	date
    echo start mkext
    start mkext | rc
}

I already had set the command line option cache numbers
before I asked about the ratios here. I had made a similar
calculation as Russ showed, but taken less space for the
user and forgotten about the default kernelpercent.
Currently I'm using fossil-open -c 12800; venti (-I -B -C)^' '^128m
which probably explains why I see in stats that mem is fully
used, and also swap space is used.
At the start of each copy-to-venti swap usage increases almost to
the max and slowly decreases until the block is copied after which
it increases again, etc.  stats really nicely shows the copying of
the blocks to venti, and the copying with mkext to fossil.

Oops. while typing this I see an error passing by; I mention
it in a separate message.


Axel.

> in the meantime, what sort of numbers in the above script are likely
> to keep fossil from filling up?