[9fans] cwfs

[arisawa]

Hello,

I have been playing with cwfs64x on 9front since last summer as my home system.
My current chief concern is, how to restore data when the disk is corrupted.
I have a copy of /dev/sdC0/fsworm on /dev/sdD0/fsworm.
However, I don't understand how to ream fscache based on the existing fsworm.
Cwfs64x complains "badtag" in fscache and exits...

I believe there is no much difference in administration between two release: Geoff's and 9front.

Kenji Arisawa.

[cinap_...@gmx.de]

see the recover command from the fsconfig(8) manual. to enter
config mode, you have to pass the -c option to cwfs. on boot, you
can do it on the bootargs line like local!/dev/sdXX/fscache -c
(thats the only 9front specific part, afaik theres no local cwfs root
filesystem support by the standard distribution)

then enter:

recover main
end

that should ream the cache and reinitialize the superblock from
the last dump.

also note, that config mode and the normal fileserver console are
different and accept different command.

i dont know to what degree your cache partition got damaged. how
did this happen? whats the tag error? is the the contents of the
configuration block on the cache still intact? if not, then you
would have to retype the filesystem configuration prior the recover
or it would have no idea what you mean with "main" filesystem name.

be carefull and good luck.

--
cinap

[arisawa]

Thanks Cinap,

that is merely an exercise for disk corruption.
I assumed /dev/sdC0 is corrupted.
the back up is on /dev/SD0 with partitions 9fat, nvram, fscache, fsworm, other,...
9fat, nvram on D0 is same as those of C0.
cwfs config in the first block of /dev/sdC0/fscache is copied to that of D0.
blocks in fsworm on C0 are copied to fsworm on D0 up to last super block (snext in console).
and then the D0 disk is moved to C0.

on reboot, I passed the -c option for the selection prompt.
the followings are my input for config prompt:
service cwfs
filsys main c(/dev/sdC0/fscache)(/dev/sdC0/fsworm)
filsys dump o
filsys other (/dev/sdC0/other)
noauth
newcache
recover
end

the response were:
check tag PC=12336 w"/dev/sdC0/fscache"(0) tag/path=<badtag> /15.....36: expected <nil>
and then returned back to the selection prompt.

why tag/path in fscache is the problem in recovering?
they must be cleaned based on fsworm.

anyone did similar exercise as me?

[arisawa]

sorry

/dev/SD0 is typo.
please replace by /dev/sdD0

Kenji Arisawa

[erik quanstrom]

> the response were:
> check tag PC=12336 w"/dev/sdC0/fscache"(0) tag/path=<badtag> /15.....36: expected <nil>
> and then returned back to the selection prompt.
>
> why tag/path in fscache is the problem in recovering?
> they must be cleaned based on fsworm.

on the real file server, the command is

recover main

note the fs name. and one would expect a stream of
"dump %lld is good; %lld next\n" messages.

peeking at the source, i would expect similar from
cwfs.

- erik

[arisawa]

Thanks, erik and cinap,

I have believed that tag/path of first block in fscache is to be created by config mode.
but not.
I retried complete copy (16KB copy) of the first block of fscache.
as erik pointed me.
recover main
end
is enough.

thanks again

Kenji Arisawa

[erik quanstrom]

> I retried complete copy (16KB copy) of the first block of fscache.
> as erik pointed me.
> recover main
> end
> is enough.

great! i've done that twice to recover something that wasn't
quite right. in both cases help from hardware, and operational
mistakes both were required to get to that point. (using aoe,
lose ethernet connection to mirror of worm while initiating
dump and rebooting instead of fixing the network connection.)

even so, i keep meaning to find the time to fix this bug. the
fs should not care when it goes down.

i've also found that the fworm device was more trouble than
it was worth to me. :-) especially in those cases, you just
rewrite the new superblock on next dump and nobody is
wiser.

- erik