Hello,
today there were problems with the Fossil FS on my Plan9 test
installation. I got first something like:
"iostate is 2 in blockwrite"
I did than the following steps.
I would like to ask if this is the right way to fix a Fossil FS? I
am new to
Plan9 but I come from the Unix world and th
> con -l /srv/fossil
> prompt: fsys main
> main: check fix
> ...
that looks plausable though its from memory,
I have not checked the manual pages in detail.
the error you saw at the start:
iostate is 2 in blockwrite
looks very reminescent of when I had a real
hardware failure on a physi
On Wed, 10 Aug 2011 17:25:53 +0200 Steve Simon
wrote:
>This is only valid if you are running venti and have have fossil
>and venti on seperate physical disks of course.
Good point. I did an installation with Fossil only. I will try to
add
a disk with Venti next. I am not sure if this works wi
> I am not sure if this works without loosing all data on the Fossil
> filesystem.
You will not lose anything.
You need to create the Venti partitions, format them, configure Venti,
remove -V in Fossil configuration and adapt your plan9.ini.
After rebooting, your Fossil will start to dump to Ve
You can migrate from fossil to fossil and venti
but it's a faf and takes quite a bit of care/reading manuals;
this is how I did it the first time I installed fossil.
reinstalling from scratch is probably easier if your fossil is
only an experimental system.
-Steve
On Wed, Aug 10, 2011 at 2:58 PM, Steve Simon wrote:
> You can migrate from fossil to fossil and venti
> but it's a faf and takes quite a bit of care/reading manuals;
> this is how I did it the first time I installed fossil.
um.
When I've done it it's been as simple as having a venti there and a
In fact, it's pretty straightforward.
In the following example, I consider you have a disk sdE0
with Fossil, and you want to add a disk sdE1 with Venti.
Create the Venti partitions:
disk/fdisk -baw /dev/sdE1/data
disk/prep -bw -a^(isect arenas bloom) /dev/sdE1/plan9
Format the Venti file system
Is it obvious enough from the man pages that this wouldn't be too useful to
have on the Plan 9 wiki?
I'm a big believer in the wiki, but not when it pushes one to avoid reading
the authoritative documentation of the man pages.
Dave
On Thu, Aug 11, 2011 at 1:11 AM, David du Colombier <0in...@gmai
David Leimbach wrote:
Is it obvious enough from the man pages that this wouldn't be too useful
to have on the Plan 9 wiki?
I'm a big believer in the wiki, but not when it pushes one to avoid
reading the authoritative documentation of the man pages.
Dave
http://www.plan9.bell-labs.com/wiki
> fsys main snaptime -s 60 -a 0530 -t 2880
Beware: there is currently a bug in fossil which can cause
it to deadlock under load if ephemerial snapshots are enabled.
This I reccomend you use a configuration more like:
fsys main snaptime -s none -a 0530 -t none
-Steve
> > fsys main snaptime -s 60 -a 0530 -t 2880
>
> Beware: there is currently a bug in fossil which can cause
> it to deadlock under load if ephemerial snapshots are enabled.
>
> This I reccomend you use a configuration more like:
>
> fsys main snaptime -s none -a 0530 -t none
As far as kno
> > Is it obvious enough from the man pages that this wouldn't be too
> > useful to have on the Plan 9 wiki?
> >
> > I'm a big believer in the wiki, but not when it pushes one to avoid
> > reading the authoritative documentation of the man pages.
>
> http://www.plan9.bell-labs.com/wiki/plan9/S
Many thanks! I will try it this weekend.
One additional question:
How much RAM needs the Fossil+Venti Fileserver in total?
-Bernd
On Thu, 11 Aug 2011 10:11:27 +0200 David du Colombier
<0in...@gmail.com> wrote:
>In fact, it's pretty straightforward.
>
>In the following example, I consider you h
> How much RAM needs the Fossil+Venti Fileserver in total?
For both Fossil and Venti, the default, in Plan 9, is to
use 20% of total user memory. These values are defined in
/sys/src/9/boot/local.c.
The minimum required memory is something like 1 MB for Fossil
and 45 MB for Venti.
Venti have thr
Actually we have since found that even scheduling archival
and temporary snapshots at different times isn't always
enough to prevent fossil from hanging during archival
snapshots.
> Actually we have since found that even scheduling archival
> and temporary snapshots at different times isn't always
> enough to prevent fossil from hanging during archival
> snapshots.
What size of fossil and venti? Can you post details of how
the servers are set up? I.e. fossil/conf and vent
I certinaly had problems a few years ago with fossil deadlocking,
since I disabled ephemeral snapshots it has been quite reliable.
My feeling (nothing more than that) was that the deadlocks seemed to
occur when I receved email just at the time of the snapshot.
the problem seemed to occur at a rat
At lsub we had deadlocks when temporary snapshots were
enable, as others. Also, fsys all sync (even with temporary snaps disabled)
sometimes hang the fossil and it no longer respond. I couldn't track this down,
we just sync fsys one by one.
hth
Done with real hardware today. Works fine.
-Bernd
On Fri, 12 Aug 2011 11:53:09 +0200 Bernd Maier
wrote:
>Many thanks! I will try it this weekend.
>
>One additional question:
>
>How much RAM needs the Fossil+Venti Fileserver in total?
>
>-Bernd
>
>On Thu, 11 Aug 2011 10:11:27 +0200 David du Col
> I certinaly had problems a few years ago with fossil deadlocking,
> since I disabled ephemeral snapshots it has been quite reliable.
>
> My feeling (nothing more than that) was that the deadlocks seemed to
> occur when I receved email just at the time of the snapshot.
>
> the problem seemed to
20 matches
Mail list logo
