From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <72882b8cb7019cbc40f3e5d226f55d19@quanstro.net> From: erik quanstrom Date: Fri, 5 Jun 2009 11:17:46 -0400 To: 9fans@9fans.net In-Reply-To: <509071940906050717o3297d18dw1035845088a710a2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] recover cwfs Topicbox-Message-UUID: 053ee4b8-ead5-11e9-9d60-3106f5b1d025 On Fri Jun 5 10:19:22 EDT 2009, anothy@gmail.com wrote: > i've got a cwfs based on an old fs(4). it gets used infrequently; > about a month and a haf ago it sufferend a power outage and i just > left it off, since i'd not touched it for a few weeks before that. > > today i brought the thing back up, and the active fs is unhappy. on > boot, it reports it can't read /adm/users, which makes mounts fail. > running newuser complains about /adm/users but adds the user to the > table in memor, so i can mount, just to get "phase error -- cannot > happen" on any file access attempt. > > accessing the dump file system works just fine. i'm entirely happy to > replace the file system with the last dump. i think "recover" from the > configuration mode is the way to do this, but i can't find a > description of it and it's been years since i had to do it. in > particular, how do i determine the superblock of the last dump? > > also, this seems like the right oportunity to start using cwfs's -c. > any notes on the performance differences? the right way to do this is to type "recover main" at the configuration prompt. since ken's fs writes the superblock as part of the dump process, it points to where the next superblock should be. so recover's algorithm is to find the first superblock at a known location and then use it to find the next superblock. lather, rince, repeat until an invalid superblock is found. the cache is wiped clean as part of this process. this is part of the normal procedure on our backup fileserver. see http://www.quanstro.net/plan9/disklessfs.pdf - erik