Having played around with cwfs for a week or so now, I'm trying to use
it to migrate my old kenfs. The relevant config line is 'filsys main
cw4f[w<0-3>]'; w4 no longer works. I've gotten w0-3 hooked up to my
cpu server and have created a devmap mapping w4 to a 30GB disk file
(the original w4 disk was slightly larger than that).

Starting up cwfs with -f (and other appropriate invocations) seems to
work fine; I give it the config, it reports the correct mapping, and I
end the conversation with 'recover main' and 'end'. The recover seems
to work fine - it reports the block numbers of a few hundred dumps -
but the process ends with this (I have CHAT(cp) always return true):
	next dump at Wed Sep 19 05:00:00 2007
	c_session 0
	c_attach 0
		fid = 1
		uid = adm
		arg = main
	fworm: read 1400715
		error: phase error -- directory entry not allocated
	panic: FID1 attach to root
	halted at Tue Sep 18 14:16:07 2007.
That phase error is Ealloc in 9p1.c^f_attach.

If I omit the -f from cwfs's invocation after doing the recover, I get
this, instead:
	next dump at Wed Sep 19 05:00:00 2007
	c_session 0
	c_attach 0
		fid = 1
		uid = adm
		arg = main
	cwfs:10685: suicide: sys: trap: divide error pc=0x000131cd
PC there points to /sys/src/cmd/cwfs/cw.c:562 - cwio(); I've got acid
traces in, but I don't see anything obviously wrong (no
divide-by-zero, h->msize is positive, &c).

In this case, only the first cwfs proc has suicided; the rest are
running along, getting 9p requests (although not managing to actually
do anything with them).

I'm going to do more tracing after dinner or tomorrow, but I'm
reasonably stumped at this point. Any pointers or other help is
greatly appreciated. Particularly intriguing is why the behavior
differs, when the first case successfully completes the recover and
moves on. Attached is a summary of an acid debugging run on the
suicided process from the second form, should anyone want to take a
look.