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

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

[Fco.J.Ballesteros]

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

I changed the constant to use 16K blocks, since I think that would
probably be better for speed and disks are big. But if you have
problems to recompile it send me a mail and I'll put a binary with
8K blocks for you to download.

hth


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

Received: from mail.cse.psu.edu ([130.203.4.6]) by aquamar; Thu Feb 28 22:19:23 MET 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 19BB819A29; Thu, 28 Feb 2002 16:19:12 -0500 (EST)
Delivered-To: 9fans@cse.psu.edu
Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id A379C199E4
	for <9fans@cse.psu.edu>; Thu, 28 Feb 2002 16:18:03 -0500 (EST)
Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12])
	by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id WAA22856
	for <9fans@cse.psu.edu>; Thu, 28 Feb 2002 22:18:01 +0100 (MET)
Received: from copernicus.cs.utwente.nl by zeus.cs.utwente.nl (8.10.2+Sun/csrelay-Sol1.4/RB)
	id g1SLHw318548; Thu, 28 Feb 2002 22:17:59 +0100 (MET)
Received: from localhost (belinfan@localhost)
	by copernicus.cs.utwente.nl (8.11.6+Sun/8.10.2) with SMTP id g1SLHxd21267
	for <9fans@cse.psu.edu>; Thu, 28 Feb 2002 22:17:59 +0100 (MET)
Message-Id: <200202282117.g1SLHxd21267@copernicus.cs.utwente.nl>
X-Authentication-Warning: copernicus.cs.utwente.nl: belinfan@localhost didn't use HELO protocol
X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #20[UCI]
To: 9fans@cse.psu.edu
Subject: Re: [9fans] fs config problem status update (still unsolved)
In-reply-to: Your message of "Thu, 28 Feb 2002 16:09:07 -0500."
             <6f1e535b5006a4d39a822acbd26f140e@plan9.bell-labs.com> 
References: <6f1e535b5006a4d39a822acbd26f140e@plan9.bell-labs.com> 
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
X-Organisation: University of Twente, Department of Computer Science,
                Formal Methods and Tools Group,
                PO Box 217, NL-7500 AE Enschede, The Netherlands
X-Phone: +31 53 4893774
X-Telefax: +31 53 4893247
X-Face: 3YGZY^_!}k]>-k'9$LK?8GXbi?vs=2v*ut,/8z,z!(QNBk_>~:~"MJ_%i`sLLqGN,DGbkT@
 N\jhX/jNLTz2hO_R"*RF(%bRvk+M,iU7SvVJtC*\B6Ud<7~`MGMp7rCI6LVp=%k=HE?-UCV?[p\$R?
 mI\n2/!#3/wZZsa[m7d;PKWiuH6'~<x[UoHs%Ei=QZA
X-Url: http://www.cs.utwente.nl/~belinfan/
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.8
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Help: <mailto:9fans-request@cse.psu.edu?subject=help>
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Thu, 28 Feb 2002 22:17:59 +0100

> > Is the ide-patched fs kernel 'compatible' with the plan9pc one?
> > Or do the on-disk structures differ (w.r.t. 'using 16K blocks') 
> 
> it's just a compile-time constant; you can recompile, right?


Certainly. But with my fs in the state that it is now,
I thought I'd try for a change to ask (a) question(s) first,
rather than only after the calf has drowned :-)
(or however you say this in english).

Thanks for confirming that indeed this is a compile time constant,
Axel.

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

[Axel Belinfante]

> I changed the constant to use 16K blocks, since I think that would
> probably be better for speed and disks are big. But if you have
> problems to recompile it send me a mail and I'll put a binary with
> 8K blocks for you to download.

Thanks for the offer. Recompiling in itself shouldn't be a problem.
After running diff between the original fs and the patched code
I was just trying to make sure which differences can be ignored
(almost all, I understand now) and which need attention
(the block size, which is (solely) determined by RBUFSIZE, correct?)

Axel.

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

[Fco.J.Ballesteros]

: After running diff between the original fs and the patched code
: I was just trying to make sure which differences can be ignored
: (the block size, which is (solely) determined by RBUFSIZE, correct?)

correct, AFAIK

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

[Axel Belinfante]

> >>Or could I use pieces of kfs?
[details omitted]
> it can be done, though.

Thanks! I'll have a look tomorrow!
Axel.

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

[forsyth]

>>Or could I use pieces of kfs?
disk/kfs reorders some of the disc structures to allow a choice of
block size on the command line, so you can't use it directly to read
an fs(8) structure.  if you're v keen or desperate, you
can do a variant of kfs that uses the file server's ordering of disc structures,
mainly by reordering structure members and making them static sizes.
it must be a good seven years ago i made the changes (for an older
version of plan 9) and i haven't got the code now.  i can't even remember
what happened that caused me to make the effort.
it can be done, though.

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

[Axel Belinfante]

> > Is the ide-patched fs kernel 'compatible' with the plan9pc one?
> > Or do the on-disk structures differ (w.r.t. 'using 16K blocks') 
> 
> it's just a compile-time constant; you can recompile, right?


Certainly. But with my fs in the state that it is now,
I thought I'd try for a change to ask (a) question(s) first,
rather than only after the calf has drowned :-)
(or however you say this in english).

Thanks for confirming that indeed this is a compile time constant,
Axel.

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

[Russ Cox]

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

it's just a compile-time constant; you can recompile, right?

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 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);
}