From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: arisawa <arisawa@ar.aichi-u.ac.jp>
In-Reply-To: <ff16a5a616d5b4af930169c6d233b437@rei2.9hal>
Date: Fri, 22 Feb 2013 19:15:28 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C524125-3AD2-40E1-B3C4-1E3ABCDC5C56@ar.aichi-u.ac.jp>
References: <ff16a5a616d5b4af930169c6d233b437@rei2.9hal>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] cwfs
Topicbox-Message-UUID: 1d373de2-ead8-11e9-9d60-3106f5b1d025

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=3D12336 w"/dev/sdC0/fscache"(0) tag/path=3D<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)
>=20
> then enter:
>=20
> recover main
> end
>=20
> that should ream the cache and reinitialize the superblock from
> the last dump.
>=20
> also note, that config mode and the normal fileserver console are
> different and accept different command.
>=20
> 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.
>=20
> be carefull and good luck.
>=20
> --
> cinap
>=20