From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9fad8e46180480a87bb08e10ebd3adcc@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Bad Karma with old kit
Date: Sun,  5 Jun 2005 13:18:54 +0200
From: lucio@proxima.alt.za
In-Reply-To: <3ceef387c19a6598d0e2767bed0c040a@collyer.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 5c2f4678-ead0-11e9-9d60-3106f5b1d025

> [Lucio, I tried to mail this to you privately, but keep getting
> 
> 	Sat Jun  4 15:16:22 PDT 2005 connect to tcp!proxima.alt.za:
> 	550 5.0.0 Access denied ]
> 
If you tell me the IP address this is happening on, I may be able to
fix it.  My exchanger is (intentionally) ridiculously strict, most
likely there are no PTR records for your end of the connection.  Sorry
about it, I can fix it this side if you can't/won't fix it on yours.
<lucio@iba.co.za> or <lucio@hivemind.net> are possible alternatives
for private mail, but they have their own mailboxes and I only inspect
them infrequently :-(

> You can compile the 64-bit fs to be compatible on-disk with the 32-bit
> fs by adding -DOLD to CFLAGS in the mkfile for that system.  It might
> be worth trying the newer code.  The old IDE code was a little weak on
> error checks.
> 
Yep, I can do that.

> Bad block size sounds like a good guess, but aren't you booting the
> same fs kernel that you used to run on this machine?  The block size
> is compiled in, so I'm not sure how it could have changed.
> 
No, I lost the original, I rebuilt it from source and I can't recall
whether originally I had changed the raw block size or not.  It won't
hurt (much) to try a few options, it did work for the 4/3/2ed server I
needed to revive (I'm on a binge of repairing equipment so it can lie
idle a little longer :-)

> I'm a little puzzled by the references in the devinit lines to D5 and
> D14; those don't look like valid file server device strings, which is
> worrisome.  It looks like `D' is a `can't happen' condition, in Zfmt()
> at /sys/src/fs/port/sub.c:602.

I thought as much, too.  But I'm totally unfamiliar with the FS code
and it used to scroll past too quickly for me to take proper notice,
specially when everything worked just fine.  I wonder if the block
size is not messing up the configuration as read off the disk.

Unusually, coming so close to recovering the filesystem, I'm willing
to go to some trouble to get back a number of useful items on that FS
for which I have no backup.  Normally I'd just give up.  I'll try
varying the raw block size first, but it's very tempting to use your
newer FS for everything.  Does it use the same dat.h entry for the
block size?  Any chance that that could be a config parameter?  Or,
even better, a detected value on existing filesystems?

++L