[9fans] 4th edition file server available

[9fans] 4th edition file server available

[Russ Cox]

The new 4th edition file server, named Fossil,
is now available on sources.  There are some
how-to docs for setting up Venti and Fossil at:

http://plan9.bell-labs.com/wiki/plan9/setting_up_venti
http://plan9.bell-labs.com/wiki/plan9/setting_up_fossil

The man pages fossil(4) and fossilcons(8) are
the definitive reference.  /sys/doc/fossil.pdf (aka
http://plan9.bell-labs.com/sys/doc/fossil.pdf)
describes the disk structures and also the Vac
structures for those interested in hacking the
internals.

Conceptually, Fossil is similar to the current file server
with Venti instead of a WORM juke box, but practically
there are many other differences.  It is a user-level
program rather than a special kernel, it speaks 9P2000
(and not 9P1), and there are numerous other improvements,
including enormous file names and also soft updates so that
the disk image is always in a consistent state.

It is still a work in progress, but it's ready to be used
by those feeling adventurous.

Enjoy.
Sean, Jim, Russ


g% x=`{perl -e 'print "a"x2000'}
g% >$x
g% ls -l $x
--rw-rw-r-- M 8 rsc rsc 0 Jan  8 01:30 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
g%

Re: [9fans] 4th edition file server available

[Axel Belinfante]

Congratulations!

I feel a bit adventurous -- but also in the need of
a little (or more?) hand-holding.

I have browsed through the setting up docs on wiki,
and a couple of the refered man pages, but
could not easily see how to build a fossil from
(to replace) an existing fake-worm file server,
taking into account the dump partition.

I recall reading before that at bell labs worm
disks of the fs were copied ``by hand'' one by one,
by taking them out of the fs.
Is there a way to transfer dump to fossil from
a running fake-worm fs (so, just using normal 9p
access, without going to the ``raw disks'')?

On a related note: my fake-worm fs uses relatively small
blocks (4Kb). Can I freely choose a block size for the
venti underlying the fossil, or should there be
a strict relation between the fake-worm  block size
and the fossil/venti block size (e.g. due to transfer
of dump blocks)?

Thanks for any insight (pointers welcome),
Axel.

> The new 4th edition file server, named Fossil,
> is now available on sources.  There are some
> how-to docs for setting up Venti and Fossil at:
[snip] 
> It is still a work in progress, but it's ready to be used
> by those feeling adventurous.

Re: [9fans] 4th edition file server available

[andrey mirtchovski]

will you put a link to it on http://plan9.bell-labs.com/sys/doc/index.html
(the index page for Volume 2 documents) or it's not yet supposed to be
read by third parties?

thanx, andrey

On Wed, 8 Jan 2003, Russ Cox wrote:

> The man pages fossil(4) and fossilcons(8) are
> the definitive reference.  /sys/doc/fossil.pdf (aka
> http://plan9.bell-labs.com/sys/doc/fossil.pdf)

Re: [9fans] 4th edition file server available

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Not to fossil, but we're using this to move our worm into vac, which
can be serviced by venti. 9fs automates it for us.

#!/bin/rc
# mkvac: creates one vac archive. argument is day number.
#

srv -q il!sargazos.escet.urjc.es
mount /srv/il!sargazos.escet.urjc.es /n/dump dump
date
vname=`{echo $1 | sed 's|/|_|g'}
lname=`{cat mkvac.last}
echo vac -s -b16k -f dump/2002/$vname.vac -d dump/2002/$lname -q /n/dump/$1
time vac -s -b16k -f dump/2002/$vname.vac -d dump/2002/$lname -q /n/dump/$1
echo echo $vname.vac '>' mkvac.last
 echo $vname.vac > mkvac.last
unmount /n/dump
rm /srv/il!sargazos.escet.urjc.es
date


This other one calls the previous one to automate it:
#!/bin/rc
days=(0508 0507 0506 .....other preferred days here)
for (d in $days) {
	cp /dev/text /n/once/nemo/mkvacs.out
	echo -n $d starts ' '
	mkvac 2002/$d
	echo
}
exit


We are doing 1.5 months per day or so.

[-- Attachment #2: Type: message/rfc822, Size: 3844 bytes --]

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 4th edition file server available
Date: Wed, 08 Jan 2003 12:09:07 +0100
Message-ID: <200301081109.h08B97629776@zamenhof.cs.utwente.nl>

Congratulations!

I feel a bit adventurous -- but also in the need of
a little (or more?) hand-holding.

I have browsed through the setting up docs on wiki,
and a couple of the refered man pages, but
could not easily see how to build a fossil from
(to replace) an existing fake-worm file server,
taking into account the dump partition.

I recall reading before that at bell labs worm
disks of the fs were copied ``by hand'' one by one,
by taking them out of the fs.
Is there a way to transfer dump to fossil from
a running fake-worm fs (so, just using normal 9p
access, without going to the ``raw disks'')?

On a related note: my fake-worm fs uses relatively small
blocks (4Kb). Can I freely choose a block size for the
venti underlying the fossil, or should there be
a strict relation between the fake-worm  block size
and the fossil/venti block size (e.g. due to transfer
of dump blocks)?

Thanks for any insight (pointers welcome),
Axel.

> The new 4th edition file server, named Fossil,
> is now available on sources.  There are some
> how-to docs for setting up Venti and Fossil at:
[snip] 
> It is still a work in progress, but it's ready to be used
> by those feeling adventurous.

Re: [9fans] 4th edition file server available

[Russ Cox]

> will you put a link to it on http://plan9.bell-labs.com/sys/doc/index.html
> (the index page for Volume 2 documents) or it's not yet supposed to be
> read by third parties?

I'm not sure it's quite ready for that.

Re: [9fans] 4th edition file server available

[Andrew]

Maybe this is in the doc's somewhere, but just do i know ahead of time,
does fossil have support for worm devices, ie HP optical jukeboxes and
such? thanks

Andrew

Re: [9fans] 4th edition file server available

[Russ Cox]

There is no support for WORM devices.
The WORM is replaced by Venti.  You could
back up Venti to a WORM drive, I suppose.

Re: [9fans] 4th edition file server available

[Fco.J.Ballesteros]

> You could
> back up Venti to a WORM drive, I suppose.

An alternate way would be to use fs(3) to setup a mirror
for your venti.

Re: [9fans] 4th edition file server available

[Axel Belinfante]

/sys/doc/fossil.pdf mentions an ``experimental file stack device'' devfs(3).
I'm just curious; is that man page available?
(could not find on plan9 web nor on sources)

Axel.

[9fans] Fossil questions

[John Packer]

Yesterday, for unknown reasons, I began having problems with
my fossil partition. Stupidly, I didn't have the most recent
vac score from the file server console. Using a score I saved
a couple of days ago, I was able to reformat the partition to
an earlier state (and so "lost" two days of archival
snapshots, etc.).

Suppose I didn't have a score at all. Is there some way to
recover the most recent score, perhaps from the venti server?

Also, though it's no big loss, is everything stored on Venti
in the last two days inaccessible?

Forgive me if this is addressed in the man pages.

John Packer

Re: [9fans] Fossil questions

[Russ Cox]

> Suppose I didn't have a score at all. Is there some way to
> recover the most recent score, perhaps from the venti server?

Yes.  Since the data is not encrypted, if you have access to
the raw disk partitions storing the arenas, you can find
anything you want.

> Also, though it's no big loss, is everything stored on Venti
> in the last two days inaccessible?

Do a pull to get the new file /sys/src/cmd/venti/printarena.c
and then

	cd /sys/src/cmd/venti
	mk 8.printarena

Then, run this on the Venti server as the host owner:

cd /sys/src/cmd/venti
ventihttp=your-server:8000
hget http://$ventihttp/index | 
awk '
 /^index=/ { blockSize=0+substr($3, 11); }
 /^arena=/ { arena=substr($1, 7); }
 /^	arena=/ { start=0+substr($5, 2)-blockSize; printf("./8.printarena -o %d %s\n", start, $3); }' |
rc |
sed -n 's/^(.*) 1$/vac:\1/p'

to get a list of all the vac archives on the server.

Russ

Re: [9fans] Fossil questions

[John Packer]

Thanks for your help, Russ. That worked nicely.

John Packer


On Tuesday, January 28, 2003, at 09:02  PM, Russ Cox wrote:

>> Suppose I didn't have a score at all. Is there some way to
>> recover the most recent score, perhaps from the venti server?
>
> Yes.  Since the data is not encrypted, if you have access to
> the raw disk partitions storing the arenas, you can find
> anything you want.
>
>> Also, though it's no big loss, is everything stored on Venti
>> in the last two days inaccessible?
>
> Do a pull to get the new file /sys/src/cmd/venti/printarena.c
> and then
>
> 	cd /sys/src/cmd/venti
> 	mk 8.printarena
>
> Then, run this on the Venti server as the host owner:
>
> cd /sys/src/cmd/venti
> ventihttp=your-server:8000
> hget http://$ventihttp/index |
> awk '
>  /^index=/ { blockSize=0+substr($3, 11); }
>  /^arena=/ { arena=substr($1, 7); }
>  /^	arena=/ { start=0+substr($5, 2)-blockSize; printf("./8.printarena 
> -o %d %s\n", start, $3); }' |
> rc |
> sed -n 's/^(.*) 1$/vac:\1/p'
>
> to get a list of all the vac archives on the server.
>
> Russ

Re: [9fans] Fossil questions

[Tharaneedharan Vilwanathan]

Hi,

I was also wondering what happens in this kind of situatation (i.e. when one
forgets the fingerprint value). This utility very useful.

The other question I had is what happens if I terminate a vac command
abruptly? Is it that the blocks (that are written till that time) are there
somewhere permanently but one cannot get them out? Or is it that some level
of clean up is done?

Regards
dharani

> Thanks for your help, Russ. That worked nicely.
>
> John Packer
>
>
> On Tuesday, January 28, 2003, at 09:02  PM, Russ Cox wrote:
>
> >> Suppose I didn't have a score at all. Is there some way to
> >> recover the most recent score, perhaps from the venti server?
> >
> > Yes.  Since the data is not encrypted, if you have access to
> > the raw disk partitions storing the arenas, you can find
> > anything you want.
> >
> >> Also, though it's no big loss, is everything stored on Venti
> >> in the last two days inaccessible?
> >
> > Do a pull to get the new file /sys/src/cmd/venti/printarena.c
> > and then
> >
> > cd /sys/src/cmd/venti
> > mk 8.printarena
> >
> > Then, run this on the Venti server as the host owner:
> >
> > cd /sys/src/cmd/venti
> > ventihttp=your-server:8000
> > hget http://$ventihttp/index |
> > awk '
> >  /^index=/ { blockSize=0+substr($3, 11); }
> >  /^arena=/ { arena=substr($1, 7); }
> >  /^ arena=/ { start=0+substr($5, 2)-blockSize; printf("./8.printarena
> > -o %d %s\n", start, $3); }' |
> > rc |
> > sed -n 's/^(.*) 1$/vac:\1/p'
> >
> > to get a list of all the vac archives on the server.
> >
> > Russ
>

Re: [9fans] Fossil questions

[Russ Cox]

When you interrupt a vac, the blocks are there
permanently and you can get them out if you know
their hashes, but of course you don't.  However,
if you store the same blocks again (you restart the
vac) they won't be stored a second time.

Russ

Re: [9fans] Fossil Questions

[Christopher Nielsen]

And of course, a little reading has answered my question.
This is what epoch is for.

On Wed, Jul 23, 2003 at 12:23:42PM -0700, Christopher Nielsen wrote:
> Is it just me or does fossil not clear the write buffer
> after 'snap -a' is performed?
>
> I am in the process of archiving my music collection to
> fossil+venti, executing 'snap -a' when the write buffer
> gets close to full. I was expecting to be able to just
> start writing to the buffer once the archival snapshot
> finished. Instead, it seems that I have to 'flfmt -v ...'
> the write buffer and restart fossil. This is a bit
> cumbersome when you have a fileserver that boots from
> fossil+venti. Also, from what I have experinced so far,
> fossil gets very cranky and does not recover gracefully
> when the write buffer is filled.
>
> I know people are on vacation and such, and I am more than
> happy to dive into the code to address this. Before I do,
> I want to make sure the behavior I am seeing is accurate
> and the behavior I expect is desired.
>
> That said, I must say the system is quite robust from a
> data safety standpoint. I've been through repeated crashes
> and have not lost any data that was archived to venti.
> Very nice work guys.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

[9fans] Fossil Questions

[Christopher Nielsen]

Is it just me or does fossil not clear the write buffer
after 'snap -a' is performed?

I am in the process of archiving my music collection to
fossil+venti, executing 'snap -a' when the write buffer
gets close to full. I was expecting to be able to just
start writing to the buffer once the archival snapshot
finished. Instead, it seems that I have to 'flfmt -v ...'
the write buffer and restart fossil. This is a bit
cumbersome when you have a fileserver that boots from
fossil+venti. Also, from what I have experinced so far,
fossil gets very cranky and does not recover gracefully
when the write buffer is filled.

I know people are on vacation and such, and I am more than
happy to dive into the code to address this. Before I do,
I want to make sure the behavior I am seeing is accurate
and the behavior I expect is desired.

That said, I must say the system is quite robust from a
data safety standpoint. I've been through repeated crashes
and have not lost any data that was archived to venti.
Very nice work guys.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin