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: <6c5658ae83ba1e8e1c89d2e55cc57ab6@brasstown.quanstro.net>
Date: Fri, 22 Feb 2013 20:33:26 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC7056FC-F590-4063-A77B-69C1186EBB5F@ar.aichi-u.ac.jp>
References: <ff16a5a616d5b4af930169c6d233b437@rei2.9hal>
	<2C524125-3AD2-40E1-B3C4-1E3ABCDC5C56@ar.aichi-u.ac.jp>
	<6c5658ae83ba1e8e1c89d2e55cc57ab6@brasstown.quanstro.net>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] cwfs
Topicbox-Message-UUID: 1d52efa6-ead8-11e9-9d60-3106f5b1d025

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

On 2013/02/22, at 19:40, erik quanstrom <quanstro@quanstro.net> wrote:

>> 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.
>>=20
>> why tag/path in fscache is the problem in recovering?
>> they must be cleaned based on fsworm.
>=20
> on the real file server, the command is
>=20
> 	recover main
>=20
> note the fs name.  and one would expect a stream of
> "dump %lld is good; %lld next\n" messages.
>=20
> peeking at the source, i would expect similar from
> cwfs.
>=20
> - erik
>=20