[9fans] fossil

[9fans] fossil

[David Presotto]

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

Re: [9fans] Interoperating between 9legacy and 9front

[Noam Preil]

> The absence of Fossil from 9front was the one I found most difficult to
> overcome, but at least in theory only the equivalent of "fossil/conf" (an
> rc script I eventually shoehorned from plan9port) is essential. I can see
> how it would be inconvenient to need to support software that is
> significantly complex, especially when it must also be able to be embedded
> in the kernel.        

Actually, adding fossil back in to 9front is extremely simple; I have a
branch at https://git.sr.ht/~pixelherodev/plan9 which has fossil
integrated.

The talk I gave at IWP9 was running from fossil on my 9front branch.

If my changes are too extensive compared to 9front (it's a personal
branch, so I wouldn't blame you for thinking that), I'm happy to even
create a branch that's just 9front+fossil. It's really not hard.

- Noam Preil


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tde2ca2adda383a3a-Mf4487e7706a5d7b4363ebe2e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] fossil

[Richard Miller]

Noam Preil:
> I have a
> branch at https://git.sr.ht/~pixelherodev/plan9 which has fossil
> integrated.

I took the liberty of having a look at the fossil source in that repo.
It seems to be missing the fossil-time-backward patch. That's on the
current 9legacy distribution ISO (built 14 April 2023), and probably
on several previous ones as it went into the 9legacy git in April 2022.

It's a two-line patch which fixes a bug where the periodic sync process
can stop working if the system clock goes backwards. The consequences
of that are failure to update on-disk file data, and exhaustion of the
in-memory cache buffers which results in deadlock. From memory, I think
it could also make the sync process go into a 100% cpu loop which might
look like deadlock.

If you apply that patch, I hope that you will find some of the problems
you've been observing will be cleared up.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbbcec90e3dd997e1-M2a3d10ef36b09cf392eda1c2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[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

[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

[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

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
>

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

[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

[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.
>