Re: [9fans] fs config problem: accidental config deletion?

Re: [9fans] fs config problem: accidental config deletion?

[forsyth]

>>Does this mean that my only chance to gain acces to the fs
>>is to indeed re-specify the complete configuration,
>>including the filsys lines, exactely as I specified them before?

the configuration is stored where you tell it,
and as you say, giving a new "config" command
causes it to reset the configuration.
you need to give it the filsys lines as before.
DO NOT INCLUDE a ream request, or you WILL be sad.
just the filsys

Re: [9fans] fs config problem: accidental config deletion?

[Axel Belinfante]

Thanks for the reply.
Will I get feedback that tells me when I guessed the
filsys string wrong?
The reason I'm asking is that I know how I configured
the fake-worm part of main, but am a bit unsure about
the cache part, that is on another disk that also
contains an empty other file-system.
Because I made a dump before switching the system off,
I don't care much about the cache nor about the (empty)
other file system, assuming that I can use 'recover main'
to reinitialise the cache.

Yes, avoiding not-intented ream is very important.
(Seemingly) a long time ago with disk/kfs I included a 
not-intended ream request, when I copied/pasted a
disk/kfs command from the man page without paying
attention to _all_ the options (i.e. overseeing the 'r' option);
luckily that was a very fresh file system,
just after installation -- it just took me time to
reinstall.

Axel.

> the configuration is stored where you tell it,
> and as you say, giving a new "config" command
> causes it to reset the configuration.
> you need to give it the filsys lines as before.
> DO NOT INCLUDE a ream request, or you WILL be sad.
> just the filsys

[9fans] fs config problem status update (still unsolved)

[Axel Belinfante]

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

For those who are interested, (and/or able to help or offer advice :-),
a short update on what I tried and how far I got.

I guessed my filsys lines, as below, but this did not give full success.
       filsys main cp(w0)0.25f(w1.<0-1>.0)
       filsys dump o
       filsys temp p(w0)25.75
I'm pretty sure that for the worm I just concatenated the two w1*
devices; I'm slightly less sure about the partitions I had chosen
for the cache and for temp (but I'm sure they make up w0).

So far I noticed the following:
 - somehow, occasionally, when reading the config info from disk,
   it turns out to be corrupted, i.e. one of the keywords has been
   changed such that it is not recognized -> panic
   After the panic, on reading again, some other keyword may be
   corrupted -> panic again, until finally the whole thing is read OK.
   Since I don't (yet) have a way to just look at (what's on) the disks,
   I don't know what's there. I intend to add another disk to the fs,
   and install p9 on it, to be able to look at the disks from it.
 
 - when it is able to read the config, the fs shows the initialisation
   that it does for main, upto and including the devinit for drives
   (devices) w1.0.0 and w1.1.0, after which it hangs -- and one time
   I waited for about an hour to see if it would make any progress,
   which it didn't.

 - with the guessed strings, I tried a config of
      recover main
   but then I got a panic message about no superblock(s)

 - I tried to add debugging print statements to see where it hangs,
   which is in cwinit, in 
        p = getbuf(cw->cdev, h->maddr + m/BKPERBLK, Bread);
   at the moment where m=260 (plus or minus a few), and
   h->msize=11000 (where I rounded to the neares thousand, I think).
   In the hope of getting more feedback I also added a checktag
   call, don't know if that is indeed the right one at the right place.
   It passes the checktag call, but that could be(?) because of the
   recover config request that I gave, even though it failed?
   (according to the source, cwrecover only invokes settag _after_
    looking for a superblock in the worm)
   For completeness I attached my debugging version of cwinit.

Now it's time for weekend; after the weekend I hope to install p9
on a new disk in the fs, to see if that gives anything.

Axel.


[-- Attachment #2: fsdebg --]
[-- Type: text/plain , Size: 863 bytes --]

void
cwinit(Device *dev)
{
	Cw *cw;
	Cache *h;
	Iobuf *cb, *p;
	long l, m;

	cwinit1(dev);

	cw = dev->private;
	l = devsize(cw->wdev);
	cb = getbuf(cw->cdev, CACHE_ADDR, Bread|Bmod|Bres);
	if(!cb || checktag(cb, Tcache, QPSUPER))		/* AFEB */
		panic("cwinit: checktag c bucket");	/* AFEB */
	h = (Cache*)cb->iobuf;
	h->toytime = toytime() + SECOND(30);
	h->time = time();
	m = h->wsize;
	if(l != m) {
		print("wdev changed size %ld to %ld\n", m, l);
		h->wsize = l;
		cb->flags |= Bmod;
	}

	for(m=0; m<h->msize; m++) {
		print("cwinit reading/checking %ld of %ld <r", m, h->msize); /* AFEB DEBUG*/
		p = getbuf(cw->cdev, h->maddr + m/BKPERBLK, Bread);
		print("><c");
		if(!p || checktag(p, Tbuck, h->maddr + m/BKPERBLK))
			panic("cwinit: checktag c bucket");
		print("><w");
		putbuf(p);
		print(">\n");
	}
	putbuf(cb);
}

Re: [9fans] fs config problem status update (still unsolved)

[Axel Belinfante]

Hoping this still doesn't bore to much, yet another short update.
Status: not solved yet.

I have added an ide disk containing a stand-alone plan 9
installation to the fs pc, and can look at the /dev/sd*/data.
On the worm I can see strings that look like data, and at
(just after the start of) the cache I see the configuration.
Would there be a way (not too involved) to extract that part
of the fs code that 'parses' the on-disk data,
to interpret it (and so see whether/where the(re) problems are)?
Or could I use pieces of kfs?

Wrt things I noticed previously:
when I do 'p /dev/sd00/data' I see the config data -
and indeed there appears a single-character error
(filsss instead of filsys, or something similar).

Is the ide-patched fs kernel 'compatible' with the plan9pc one?
Or do the on-disk structures differ (w.r.t. 'using 16K blocks') 

Thanks,
Axel.

[9fans] fs config problem: accidental config deletion?

[Axel Belinfante]

Hello,

due to a change of IP number I had to reconfigure my fs.
I rebooted, went to config mode, and tried to change
just ip and ipgw:
 	ip new.ip.address
	ipgw new.ip.g.w
	end
I think at a certain moment I made a typing mistake,
but typed 'end' anyway. Anyway, all I got after config
were panics.

Then I did something silly: I also (re)configured 'service'
and 'config', and  the other ip address, basically everything
except the filsys's:
	service super
	config w0
	...
	end
and now I have the funny feeling that, by re-specifying config,
I have blown away my filsys configuration, confirmed by
panic(no filsys) (and a -- too late -- look at the source).

Does this mean that my only chance to gain acces to the fs
is to indeed re-specify the complete configuration,
including the filsys lines, exactely as I specified them before?
(the unfortunate thing is that I played a bit with filsys lines
 to get it working, and even though I have a pretty good idea,
 I am not completely sure what filsys strings I finally specified)
Or is the configuration stored elsewhere, or can it somehow be
'reverse engineered'?

Feeling, ahem, not so bright this morning,
Axel.