From owner-freebsd-bugs Tue Jul 17 14: 0:12 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B9B5637B405 for ; Tue, 17 Jul 2001 14:00:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f6HL03s82249; Tue, 17 Jul 2001 14:00:03 -0700 (PDT) (envelope-from gnats) Date: Tue, 17 Jul 2001 14:00:03 -0700 (PDT) Message-Id: <200107172100.f6HL03s82249@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Ian Dowse Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Reply-To: Ian Dowse Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR i386/29045; it has been noted by GNATS. From: Ian Dowse To: Bill Moran Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: i386/29045: Heavy disk usage causes panic in ffs_blkfree Date: Tue, 17 Jul 2001 21:51:30 +0100 In message <200107171753.f6HHrPd52978@freefall.freebsd.org>, Bill Moran writes: > >Under heavy load, panics occur in the filesystem code. The panics apparently r >esult in some sort of subtle corruption to the filesystem that then results in > an increased chance of further panics. It's always difficult to tell if these panics are caused by a hardware/driver fault, or by filesystem bugs. Could you try printing out some more information including the contents of the free block bitmap from frame 2 on the stack - i.e. something like frame 2 p fs p *fs p fs->fs_fpg p bp->b_data p cg p cgp p *cgp p bno p blksfree p blksfree[0]@(fs->fs_fpg/8) A good test for hardware/driver faults is to take some large directory tree that does not change, especially one with lots of huge files, and run find /whatever -type f -print0 |xargs -0 md5 > /tmp/md5.1 find /whatever -type f -print0 |xargs -0 md5 > /tmp/md5.2 find /whatever -type f -print0 |xargs -0 md5 > /tmp/md5.3 etc while the system is under heavy load. Then diff the /tmp/md5.X files to see if anything has changed. You should try this with trees on different disks in case there is a driver/disk dependent corruption problem. Also try leaving quite a long gap between running the finds; data could be getting corrupted as it sits in the buffer cache. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message