From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] file server trouble From: forsyth@vitanuova.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-guuxlfpcnvmsgpxykeagbpzazh" Message-Id: <20020403170103.C42131999B@mail.cse.psu.edu> Date: Wed, 3 Apr 2002 17:56:58 +0100 Topicbox-Message-UUID: 727048c0-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-guuxlfpcnvmsgpxykeagbpzazh Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit i wouldn't necessarily suspect the drive. it's saying that the fworm bitmap claims a block has already been written, which isn't allowed on a write-once structure. thats fine, except it might have been interrupted at some point when the fworm bitmap had been written but pointers in the super block and other structures updating the allocation addresses had not been written. the data might or might not be in those blocks. actually, i'd suspect it had crashed or rebooted during a dump. do the recover again, but try a kernel that uses a larger value in cw.c for h->fsize = s->fsize + 100; /* this must be conservative */ you could also just comment out the fworm diagnostic. i've done that in the past but i knew it was safe in those cases because i had a clearer picture of its state when it crashed. --upas-guuxlfpcnvmsgpxykeagbpzazh Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-1.mail.demon.net by mailstore for forsyth@vitanuova.com id 1017852164:10:27012:9; Wed, 03 Apr 2002 16:42:44 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-1.mail.demon.net id aa1127866; 3 Apr 2002 16:42 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.30.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id E74B019A56; Wed, 3 Apr 2002 11:42:06 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from cosym.net (unknown [64.7.3.116]) by mail.cse.psu.edu (CSE Mail Server) with SMTP id 3E2F319A55 for <9fans@cse.psu.edu>; Wed, 3 Apr 2002 11:41:50 -0500 (EST) To: 9fans@cse.psu.edu Subject: Re: [9fans] file server trouble MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Message-Id: <20020403164150.3E2F319A55@mail.cse.psu.edu> Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Wed, 3 Apr 2002 11:39:44 -0500 thanks to geoff's pointers, i was able to build a kernel that correctly recovered my file system. the file server is back up, and stays running in the face of normal use. but things still arn't "right". i'm now getting lots of messages of the following form on my file server console: fworm: write 152116 cwio: write induced dump error - w worm fworm: write 152117 cwio: write induced dump error - w worm fworm: write 152151 cwio: write induced dump error - w worm fworm: write 152152 cwio: write induced dump error - w worm this started after a dump was attempted. the above block would repeat every few seconds (~10). after the next dump, a new set was generated, with about twice the number of errors, printing about ever 20 seconds. this looks to me like a bad disk (which is really annoying, since it's a few months old). do others agree? between now and when i can get the disk replaced, is there any mechanism in the fs kernel for marking blocks "bad"? and if not, am i correct in my belief that all my dumps into the future will be unsafe, since dumps include all the previous blocks (until modification)? --upas-guuxlfpcnvmsgpxykeagbpzazh--