Re: [9fans] fs partwrite

Re: [9fans] fs partwrite

[forsyth]

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

there's another possible cause of the partwrite message, given
that you had some trouble with the configuration before.
it's trying to use block addresses stored in the file system that
are either incorrect (because they were previously corrupted
by the errors), or the addresses were correct for the old
configuration but now lie beyond the configuration you're now
using (ie, it's not quite right yet).


[-- Attachment #2: Type: message/rfc822, Size: 3594 bytes --]

To: 9fans@cse.psu.edu
Subject: [9fans] fs problem: solved!!!
Date: Sat, 02 Mar 2002 00:17:43 +0100
Message-ID: <200203012317.g21NHhg21095@copernicus.cs.utwente.nl>

For those interested:
I finally succeeded to solve the problem.

I tried the "when all else fails, check the hardware" approach.
Turned out that the read/write errors I got on my cache/config
disk were caused by a scsi termination problem.

As a side effect, turned out that I have two more scsi disks
(in an external box)  than I thought. These may come in handy
to copy nemo's set-up of automatically backing up the worm --
as soon as I have these disks working together with the internal disk.
(currently the scsi host adapter card (asus pci-875) doesn't
 want to see the internal and external disks at the same time,
 probably due to addressing or termination problems, but this
 is for after the weekend).

Wasted a lot of time, learned a lot, and now it's (almost)
time for weekend (after cleaning up the hardware).

Axel. (who is _very_ happy to have his fs back!!)

Re: [9fans] fs partwrite

[Axel Belinfante]

(Replying to more than one message at the same time.)

> you should get a more precise message if the cache is full.
> similarly if the whole thing fills up.

yes, I understand. So far I just got a lot of partwrite
messages, all mentioning only two blocks numbers that are
'beyond the horizon' (if there are more, they drowned in the
message about those two).

> it's more likely that there's something wrong with the
> configuration.  what was it?

I'm now typing from memory (got details down on paper and
on the disk -- indeed I succeeded on browsing the disk using
xd/od on the data partition)

  filsys main cp(w0)0.25f(w1.<0-1>.0)
  filsys dump o
  filsys temp p(w0)25.75

> of course, one advantage of posting it here is that if
> you lose it again, you can get it from the list!
agreed! :-)  (even from my own outbox)

> there's another possible cause of the partwrite message, given
> that you had some trouble with the configuration before.
> it's trying to use block addresses stored in the file system that
> are either incorrect (because they were previously corrupted
> by the errors), or the addresses were correct for the old
> configuration but now lie beyond the configuration you're now
> using (ie, it's not quite right yet).

I guess that it is the second thing.
Problem is that I'm not sure about the partition percentages for w0,
only about order. So far I guessed 25% cache 75% temp (which are also
among the notes I made during the original config, but due to the
coprruption problems caused by the misconfigured scsi termination 
I think I played a bit with the config until I happened to get
something that just worked.)
'temp' is probably only reamed when I made the original config,
and never used after that.

Among the sysinit messages I did not see anything about not
finding temp (but I still have to look at the source to see
how much sanity checks sysinit does on a non-cw filsys).

I tried looking at the disk with xd (and od on lunix), in the hope
of finding traces of the ream of temp, (superblock etc., as I did
find for the cache and (on another disk) for the worm) -- assuming
those traces are there to be found -- assuming it does leave traces
similar to those for the cache and worm (still need to check the
source) but getting so far on the disk seemed to take more time than
I was willing to wait for so far, even combined with a 'grep' on the
xd/od output. I tried playing with tail to start the xd/od around
halfway on the disk, but 1) I realised I should make more exact
calculations of where to start looking 2) if I try to give a huge
offset, I get a message of (linux) tail that the offset cannot be
represented.
Or probably I could take the fs portdat.h data structures (basically
just for: block = data + tag), and built my own dedicated tag searcher
to look for temp superblock etc, maybe that's an idea...

Axel.

Solved! (was: Re: [9fans] fs partwrite)

[Axel Belinfante]

Just to keep you informed :-)
Today I had finally time again for this problem.

I tried config
   filsys main cp(w0)0.50f(w1.<0-1>.0)
   filsys dump o
   filsys temp p(w0)50.50
and the problems seem to be gone
(and this config is now nicely documented in the 9fans mail archive :-)

I issued 'check' commands for main and temp,
and they did not find errors given this config
(they did report problems for the previous config, listed below --
 part(read/write)? errors for main, and a panic for temp
 (forgot actual error message))
Now, for temp I also issued 'check rdall' which succeeded,
so I suppose, finally, 'problem closed'!

Thanks to all who helped and offered support!

Regards,
Axel.

> 
> > it's more likely that there's something wrong with the
> > configuration.  what was it?
> 
> I'm now typing from memory (got details down on paper and
> on the disk -- indeed I succeeded on browsing the disk using
> xd/od on the data partition)
> 
>   filsys main cp(w0)0.25f(w1.<0-1>.0)
>   filsys dump o
>   filsys temp p(w0)25.75
> 
> > of course, one advantage of posting it here is that if
> > you lose it again, you can get it from the list!
> agreed! :-)  (even from my own outbox)

Re[2]: [9fans] fs partwrite

[steve.simon]

>...Or probably I could take the fs portdat.h data structures (basically
>just for: block = data + tag), and built my own dedicated tag searcher
>to look for temp superblock etc, maybe that's an idea...


Brings back memories... rebuilding a Unix sys-V database disk that had
been burnt (The machine went on fire!) It had vital data for a
haulage firm (Where all the goods and trucks where); the backup
QIC tapes had been stored on top of the machine.

Marvelous fun :-)

-Steve



----------------------------------------------------------------------
The contents of this communication are confidential to the normal user of
the email address to which it was sent.  If you have received this email
in error, any use, dissemination, forwarding, printing or copying of this
email is strictly prohibited.  If this is the case, please notify the
sender and delete this message.
---------------------------------------------------------------------- 

Re: [9fans] fs partwrite

[Boyd Roberts]

steve.simon@snellwilcox.com wrote:
> Brings back memories... rebuilding a Unix sys-V database disk that had
> been burnt (The machine went on fire!) It had vital data for a
> haulage firm (Where all the goods and trucks where); the backup
> QIC tapes had been stored on top of the machine.

The story I heard about the Crédit Lyonnais [Paris] fire was that they
send some [bunch of] sysadmin[s] in to get the tapes while the building
was burning ...

Then, they found out the safe deposit boxes weren't waterproof ...