Re: [9fans] fs partwrite

[Axel Belinfante <Axel.Belinfante@cs.utwente.nl>]

(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.