From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Sun, 8 Jun 2014 00:49:28 +0100 Message-ID: From: Riddler To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c3cbd4f34de404fb47a09b Subject: Re: [9fans] Question about fossil Topicbox-Message-UUID: f77bd012-ead8-11e9-9d60-3106f5b1d025 --001a11c3cbd4f34de404fb47a09b Content-Type: text/plain; charset=UTF-8 On 8 Jun 2014 00:19, "Steve Simon" wrote: > > sadly if fossil overflows it is terminal. > > having said this you can refresh your fossil from the last snapshot, > so not everything has gone, but the rule is don't let fossil overflow. Good to know. > your venti size sounds very big. Perhaps you have a lot of media files, > but remember that duplicate files are merged and take up only one file's > worth of space (de-duplication is done on the files contents not on its name. > > also all data is compressed so it takes less space. I wasn't thinking "I would need a big venti", more "I only need a small fossil". My train of thought was because the fossil size is used to store the unarchived files after which they can be gotten from venti that it might be practical to only have the fossil be big enough to store the maximal size of files that will change per day(snapshot interval). I would struggle to change 16GB a day unless I'm backing up a VM so 64 seemed like it should accommodate any changes and still leave room for lots of often used files to be kept there (if fossil thinks like that). I realise there would be a delay as fossil realises it needs to fall back on venti but I was thinking as they're the same PC and disk the delay would be negligible. --001a11c3cbd4f34de404fb47a09b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 8 Jun 2014 00:19, "Steve Simon" <steve@quintile.net> wrote:
>
> sadly if fossil overflows it is terminal.
>
> having said this you can refresh your fossil from the last snapshot, > so not everything has gone, but the rule is don't let fossil overf= low.

Good to know.

> your venti size sounds very big. Perhaps you have a lot= of media files,
> but remember that duplicate files are merged and take up only one file= 's
> worth of space (de-duplication is done on the files contents not on it= s name.
>
> also all data is compressed so it takes less space.

I wasn't thinking "I would need a big venti", = more=C2=A0 "I only need a small fossil". My train of thought was = because the fossil size is used to store the unarchived files after which t= hey can be gotten from venti=C2=A0that it might be practical to only have t= he fossil be big enough to store the maximal size of files that will change= per day(snapshot interval).

I would struggle to change 16GB a day unless I'm backing= up a VM so 64 seemed like it should accommodate any changes and still leav= e room for lots of often used files to be kept there (if fossil thinks like= that).

I realise there would be a delay as fossil realises it needs= to fall back on venti but I was thinking as they're the same PC and di= sk the delay would be negligible.

--001a11c3cbd4f34de404fb47a09b--