From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: Ole-Hjalmar Kristensen Date: Tue, 12 Dec 2017 21:31:05 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary="089e08212b80c73c4805602a879e" Subject: Re: [9fans] A potentially useful venti client Topicbox-Message-UUID: c63b5af8-ead9-11e9-9d60-3106f5b1d025 --089e08212b80c73c4805602a879e Content-Type: text/plain; charset="UTF-8" I can understand that it cannot fill up. What I do not understand is why there are no safeguards in place to ensure that it doesn't. (And my inner geek wants to know) As you say, in reality it will not fill up unless you dump huge amounts of data on it at once. Unfortunately, this is just what I intended to do, dump a 1.5 TB Linux file system on it. :-) On Tue, Dec 12, 2017 at 9:15 PM, Steve Simon wrote: > Re: fossil > > Fossil must not fill up, however I would say that the dropoff was the lack > of clear > documentation stating this. > > Fossil has two modes of operation. > > As a stand alone filesystem, not really intented (I believe) as a > production > system, more as a replacement for kfs - for laptops or installation > systems. > > A full fossil system is when it is combined with a local venti (venti on > the same > machine or on a fast, low latency network connection). Here most files are > pulled > from venti (in the limit fossil only contains a single score which > redirects the root > of the filesystem to a venti score. However as you change files the new > version > is stored on fossil. > > Every night aty 4 or 5 am (by convention) fossil does a snap, bumps it > epoch which > marks all the changed files as readonly and further changes creates a new > file. > The readonly files are then written to venti in the background and their > space in fossil > reclaimed. > > This means the fossil only needs to be big enough to contain all the > changes you > are likely to make in a day - in reality 10Gb or fossil will never fill up > unless > you decide to archive your entire dvd collection on the same day. > I have been running fossil and venti since 2004. Fossil did have problems > doing > ephemerial dumps (short lived dumps every 15 mins which live for a few > days). > This bug used to cause occasional fossil crashes but venti never lost a > byte. > > The bug was fixed before the labs froze and fossil has been solid since. > > I used an ssd for venti which helps its performance, though even with this > it will > never match liniux filesystem performance (cwfs may well do better), but I > know it > and its fast enough for me for now. > > -Steve > > --089e08212b80c73c4805602a879e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can understand that it cannot fill up. What I do no= t understand is why there are no safeguards in place to ensure that it does= n't. (And my inner geek wants to know)
As you say, in reality = it will not fill up unless you dump huge amounts of data on it at once. Unf= ortunately, this is just what I intended to do, dump a 1.5 TB Linux file sy= stem on it. :-)

On Tue, Dec 12, 2017 at 9:15 PM, Steve Simon <= ;steve@quintile.net= > wrote:
Re: fossil

Fossil must not fill up, however I would say that the dropoff was the lack = of clear
documentation stating this.

Fossil has two modes of operation.

As a stand alone filesystem, not really intented (I believe) as a productio= n
system, more as a replacement for kfs - for laptops or installation systems= .

A full fossil system is when it is combined with a local venti (venti on th= e same
machine or on a fast, low latency network connection). Here most files are = pulled
from venti (in the limit fossil only contains a single score which redirect= s the root
of the filesystem to a venti score. However as you change files the new ver= sion
is stored on fossil.

Every night aty 4 or 5 am (by convention) fossil does a snap, bumps it epoc= h which
marks all the changed files as readonly and further changes creates a new f= ile.
The readonly files are then written to venti in the background and their sp= ace in fossil
reclaimed.

This means the fossil only needs to be big enough to contain all the change= s you
are likely to make in a day - in reality 10Gb or fossil will never fill up = unless
you decide to archive your entire dvd collection on the same day.
I have been running fossil and venti since 2004. Fossil did have problems d= oing
ephemerial dumps (short lived dumps every 15 mins which live for a few days= ).
This bug used to cause occasional fossil crashes but venti never lost a byt= e.

The bug was fixed before the labs froze and fossil has been solid since.
I used an ssd for venti which helps its performance, though even with this = it will
never match liniux filesystem performance (cwfs may well do better), but I = know it
and its fast enough for me for now.

-Steve


--089e08212b80c73c4805602a879e--