From owner-freebsd-stable@FreeBSD.ORG Fri May 16 12:27:59 2008 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CA7C1065731 for ; Fri, 16 May 2008 12:27:59 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BA908FC1E for ; Fri, 16 May 2008 12:27:59 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 2D7581CC033; Fri, 16 May 2008 05:27:59 -0700 (PDT) Date: Fri, 16 May 2008 05:27:59 -0700 From: Jeremy Chadwick To: Willy Offermans Message-ID: <20080516122759.GA61346@eos.sc1.parodius.com> References: <20080421190403.GA4625@wiz.vpn.offrom.nl> <20080421201047.GB6884@slackbox.xs4all.nl> <20080516121414.GD4618@wiz.vpn.offrom.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080516121414.GD4618@wiz.vpn.offrom.nl> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Roland Smith , freebsd-stable@FreeBSD.ORG Subject: Re: g_vfs_done error third part--PLEASE HELP! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 12:27:59 -0000 On Fri, May 16, 2008 at 02:14:14PM +0200, Willy Offermans wrote: > On Mon, Apr 21, 2008 at 10:10:47PM +0200, Roland Smith wrote: > > Did you notice any file corruption in the filesystem on ar0s1g? > > No the two disks are brand new and I did not encounter any noticeable > file corruption. However I assume that nowadays bad sectors on HD are > handled by the hardware and do not need any user interaction to correct > this. But maybe I'm totally wrong. You're right, but it depends on the type of disk. SCSI disks will report bad blocks to the OS regardless if it is about to mark the block as a grown defect or not. PATA and SATA disks, on the other hand, will report bad blocks to the OS only if the internal bad block list (which it manages itself -- this is what you're thinking of) is full. There are still many conditions where PATA and SATA disks can induce errors in the OS. If the disk is attempting to work around a bad block, and there's a physical error (servo problem, head crash, repetitive re-reads of the block due to dust, whatever -- something that "ties up" the disk for long periods of time), ATA subsystem timeouts may be seen, DMA errors, or whatever else. SMART stats will show this kind of problem. > > Unmount the filesystem and run fsck(8) on it. Does it report any errors? > > sun# fsck /dev/ar0s1g > ** /dev/ar0s1g > ** Last Mounted on /share > ** Phase 1 - Check Blocks and Sizes > INCORRECT BLOCK COUNT I=34788357 (272 should be 264) > CORRECT? [yn] y > > INCORRECT BLOCK COUNT I=34789217 (296 should be 288) > CORRECT? [yn] y > > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > FREE BLK COUNT(S) WRONG IN SUPERBLK > SALVAGE? [yn] y > > SUMMARY INFORMATION BAD > SALVAGE? [yn] y > > BLK(S) MISSING IN BIT MAPS > SALVAGE? [yn] y > > 182863 files, 17282440 used, 120206472 free (12448 frags, 15024253 > blocks, 0.0% fragmentation) > > ***** FILE SYSTEM MARKED CLEAN ***** > > ***** FILE SYSTEM WAS MODIFIED ***** > > The usual stuff I would say. How is this usual?. It appears to me you did have some filesystem corruption. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |