[9fans] fossil

[9fans] fossil

[Andrew]

This has been nagging at me for a while. Currently my plan9 system has
the standard old fs server, and auth server and some terms. Everything
boots from floppies or small hard drives, then mounts its root from the
file server. I want to update to fossil, and do away with the old file
server. Is there an [easy] way to make the fossil server boot up on its
own in the same way fs does? Im just not really clear on how it all
fits together.

Re: [9fans] fossil

[Russ Cox]

The wiki has instructions about making a standalone fossil boot kernel.
It's not quite as simple as the current fs, but it's not too hard.
I put a link to the "Setting up Fossil" page on the front page.  Not sure
why it wasn't there already.

Re: [9fans] fossil

[Andrew]

I had read that, it seemed a little forbidding so i wanted to check if
there was an easier or better way around it first. Thanks.

Andrew

On Tue, Apr 15, 2003 at 11:12:45AM -0400, Russ Cox wrote:
> The wiki has instructions about making a standalone fossil boot kernel.
> It's not quite as simple as the current fs, but it's not too hard.
> I put a link to the "Setting up Fossil" page on the front page.  Not sure
> why it wasn't there already.
>

Re: [9fans] fossil

[erik quanstrom]

On Thu Jun  4 05:11:02 EDT 2009, forsyth@terzarima.net wrote:
> anyone else ever seen things like this from fossil? it seems a bit wayward...
>
> # on the fossil console, after `disk full' returned in errors:
>
> main: df
> 	main: 10,046,783,488 used + 35,180,756,598,784 free = 6,431,293,440 (156% used)
> main: snapclean 3600
> main: df
> 	main: 3,000,909,824 used + 3,430,383,616 free = 6,431,293,440 (46% used)

i suspect the free should be printed as a signed quanity. ☺

the management of fl->nused seems to permit a hole
(which isn't new) that could prevent fl->nused from being
decremented while still removing stuff from the fl in doRemoveLink.

perhaps i've misread the code.

it would be interesting to see what the difference between
the output of df would be if cacheCountUsed could be
asked to return both the cached fl->nused and also compute
it as it does if the epochs don't match.

it would be even more interesting if they differ, if resetting
fl->nused with the newly computed value just does the right
thing.

- erik

[9fans] fossil

[Charles Forsyth]

anyone else ever seen things like this from fossil? it seems a bit wayward...

# on the fossil console, after `disk full' returned in errors:

main: df
	main: 10,046,783,488 used + 35,180,756,598,784 free = 6,431,293,440 (156% used)
main: snapclean 3600
main: df
	main: 3,000,909,824 used + 3,430,383,616 free = 6,431,293,440 (46% used)

the server goes into `disk full' state.  i think one underlying problem
is that i haven't applied the change to remove floating-point calculations
from fossil's timer routine, and thus at least sometimes it can never quite
get to the right time to do the snapclean itself.  even so, i've only seen
this effect since i updated fossil in january after several years.
i've had periodic `disk full' problems since then.

Re: [9fans] fossil

[Russ Cox]

> ok.  it's happened again.  i have a buggered fossil on a machine
> that uses fossil as its root.  (corrupted superblock).  i have no idea
> how it happened. i guess the obvious is to rebuild the machine
> with an extra disk and cd-rom and boot from that and poke around.
> any chances of retrieving the significant work i've done since the
> last venti snap?

brucee and i figured this out.  there was a bug in the epoch
command.  if you ran epoch 0 or even epoch foo (or epoch
help!) then epoch would set the low epoch to 0, resulting in
an invalid super block.

the bug is fixed on sources.  until you rebuild fossil and your
kernels, be careful what you say to "epoch".

russ

Re: [9fans] fossil

[Russ Cox]

if you've been doing regular non-venti snaps,
the super-block actually has very little important data.
the really important part is the root blocks.  every new
file system snapshot has a new root block, and a root
block is enough to get the rest of the system.

On Tue, 4 Jan 2005 05:37:45 +1100, Bruce Ellis <bruce.ellis@gmail.com> wrote:
> ok.  it's happened again.  i have a buggered fossil on a machine
> that uses fossil as its root.  (corrupted superblock).  i have no idea
> how it happened. i guess the obvious is to rebuild the machine
> with an extra disk and cd-rom and boot from that and poke around.
> any chances of retrieving the significant work i've done since the
> last venti snap?
> 
> brucee
>

[9fans] fossil

[Bruce Ellis]

ok.  it's happened again.  i have a buggered fossil on a machine
that uses fossil as its root.  (corrupted superblock).  i have no idea
how it happened. i guess the obvious is to rebuild the machine
with an extra disk and cd-rom and boot from that and poke around.
any chances of retrieving the significant work i've done since the
last venti snap?

brucee

[9fans] fossil

[Russ Cox]

there's a new fossil on sources that should
fix the leaks people have been encountering.
as i mentioned in the other thread, the
console "check" command should be used
in place of flchk.  in particular, to fix your leaks
you can do

fsys main
check fix pdir

(of course, snap -a and wait for the vac first,
just in case.)  the pdir is optional, but it is good
for seeing that something is going on.

russ

[9fans] fossil

[David Presotto]

We fixed a pretty major security whole on Mar 11th.
Make sure you're up to date.