From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] file server trouble
From: Geoff Collyer <geoff@collyer.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20020402230659.0192919A26@mail.cse.psu.edu>
Date: Tue,  2 Apr 2002 15:06:49 -0800
Topicbox-Message-UUID: 723351fe-eaca-11e9-9e20-41e7f4b1d025

plan9pc/9pcfs.c contains

Startsb	startsb[] =
{
	"main",		2892792,
	0
};

The number is the block address of the first super block to consult
when performing a recovery.  For worms, this can be safely set to 2,
the address of the very first super block (SUPER_ADDR).  Larger values
are presumably optimisations, but this shouldn't matter much unless
you've actually got a jukebox.  emelie/9pcfs.c contains this instead:

Startsb	startsb[] =
{
	"main",		2,
	0
};

and that's probably what plan9pc/9pcfs.c should contain too.  2892792
looks like a left-over optimisation from some past file server.
clone/clone.c has yet a different (probably incorrect) value:

Startsb	startsb[] =
{
	"main",	3066839,
	0
};

So try using a value of 2.  Build & boot that kernel and try recover
again.  You can also override this value for the purpose of recovery
by setting conf.firstsb in localconfinit().  emelie/pc.c does this:

	conf.firstsb = 13219302;

and my copy of plan9pc/pc.c does this:

	conf.firstsb = 2;

but it looks like I added that.  I have done successful recovers with
firstsb == 2.  Out of paranoia, I also set

	conf.dumpreread = 1;	/* read and compare in dump copy */