2007/3/22, Richard Miller <[EMAIL PROTECTED]>:
Devon - don't panic ;)
Trying not to. I'm just really confused, and the sentiment seems to be
``WTF is wrong with you, it's plainly obvious how this works.'' But
from what everyone says, it's not working that way for me.
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.)
I'm confused then. When I type snap -a, and then run fsys main df in
fossilcons, I'm only noticing the usage going down by about 2GB/day.
If I run snap -a, wait a bit, and then run fsys main df, I notice no
change in disk usage.
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
Yep:
10.0.0.10# con -l /srv/fscons
prompt: fsys main snaptime
snaptime -a 0500 -s 60 -t 2880
I should note that I've manually modified this to happen a few times a
day. Each time, my usage goes down a couple gigs. Why doesn't it just
go ahead and sync everything?
--dho
-- Richard
