From owner-cvs-all  Thu Feb 24 12:43:27 2000
Delivered-To: cvs-all@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3A7E637B891; Thu, 24 Feb 2000 12:43:23 -0800 (PST)
	(envelope-from dillon@FreeBSD.org)
Received: (from dillon@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id MAA17349;
	Thu, 24 Feb 2000 12:43:22 -0800 (PST)
	(envelope-from dillon@FreeBSD.org)
Message-Id: <200002242043.MAA17349@freefall.freebsd.org>
From: Matt Dillon <dillon@FreeBSD.org>
Date: Thu, 24 Feb 2000 12:43:22 -0800 (PST)
To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/ufs/ffs ffs_balloc.c
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

dillon      2000/02/24 12:43:22 PST

  Modified files:
    sys/ufs/ffs          ffs_balloc.c 
  Log:
      Fix a 'freeing free block' panic in UFS.  The problem occurs when the
      filesystem fills up.  If the first indirect block exists and FFS is able
      to allocate deeper indirect blocks, but is not able to allocate the
      data block, FFS improperly unwinds the indirect blocks and leaves a
      block pointer hanging to a freed block.  This will cause a panic later
      when the file is removed.  The solution is to properly account for the
      first block-pointer-to-an-indirect-block we had to create in a balloc
      operation and then unwind it if a failure occurs.
  
  Detective work by: Ian Dowse <iedowse@maths.tcd.ie>
  Reviewed by: mckusick, Ian Dowse <iedowse@maths.tcd.ie>
  Approved by: jkh
  
  Revision  Changes    Path
  1.26      +25 -2     src/sys/ufs/ffs/ffs_balloc.c



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message