[9fans] Fossil Questions

[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

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] 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%

[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