From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9af9f7ac925b7473a4a1759d743f31fd@hamnavoe.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Update on Fossil+Venti Stuff
From: Richard Miller <9fans@hamnavoe.com>
Date: Thu, 22 Mar 2007 10:04:20 +0000
In-Reply-To: <9ab217670703211317o1958d9b3u647f6ac4fac758cd@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 2db40db8-ead2-11e9-9d60-3106f5b1d025

Devon - don't panic ;)

> that files have to be deleted from Fossil before they'll end up in
> Venti.

No, it's the other way round.  A file's blocks can be deleted from
fossil (automatically) after they have been archived to Venti,
provided they haven't been modified since.  The file's metadata
will remain on fossil.

The caveat is that blocks are archived to venti only when a snapshot
is made (either periodically as scheduled by the snaptime command
in fossilcons(8), or on request by the 'snap -a' command).  So if
the fossil partition fills with dirty (new or modified) blocks in
between snapshots, bad things happen.

Say you have a 4GB fossil partition.  If you have snaptime set to
take archival snapshots once a day, you can go on copying new mp3s
to your fossil fs, without deleting anything, provided you never copy
in more than 4GB per day.  If you're impatient, you can copy 4GB,
do a 'snap -a', copy another 4GB and so on.  (The copying of snapshot
blocks will go on in the background, so the 'snap' only freezes the
fs very briefly.)

If your fossil is getting "fuller and fuller", are you sure you
have set it up to take periodic snapshots?  You can check like this:

% con -l /srv/fscons
prompt: fsys main snaptime
    snaptime -a 0000 -s 60 -t 1440

-- Richard