9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: lucio@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	[thread overview]
Message-ID: <9fad8e46180480a87bb08e10ebd3adcc@proxima.alt.za> (raw)
In-Reply-To: <3ceef387c19a6598d0e2767bed0c040a@collyer.net>

> [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



  reply	other threads:[~2005-06-05 11:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-04 13:18 lucio
2005-06-04 22:26 ` geoff
2005-06-05 11:18   ` lucio [this message]
2005-06-05 21:49     ` geoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9fad8e46180480a87bb08e10ebd3adcc@proxima.alt.za \
    --to=lucio@proxima.alt.za \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).