From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Fri, 22 Feb 2013 05:40:44 -0500
To: 9fans@9fans.net
Message-ID: <6c5658ae83ba1e8e1c89d2e55cc57ab6@brasstown.quanstro.net>
In-Reply-To: <2C524125-3AD2-40E1-B3C4-1E3ABCDC5C56@ar.aichi-u.ac.jp>
References: <ff16a5a616d5b4af930169c6d233b437@rei2.9hal>
	<2C524125-3AD2-40E1-B3C4-1E3ABCDC5C56@ar.aichi-u.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] cwfs
Topicbox-Message-UUID: 1d44951e-ead8-11e9-9d60-3106f5b1d025

> 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