Re: [9fans] cwfs

[arisawa <arisawa@ar.aichi-u.ac.jp>]

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?

On 2013/02/22, at 17:55, cinap_lenrek@gmx.de wrote:

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