From owner-cvs-all  Sat Oct  3 12:17:20 1998
Return-Path: <owner-cvs-all>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA15699
          for cvs-all-outgoing; Sat, 3 Oct 1998 12:17:20 -0700 (PDT)
          (envelope-from owner-cvs-all)
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA15694;
          Sat, 3 Oct 1998 12:17:18 -0700 (PDT)
          (envelope-from nate@FreeBSD.org)
From: Nate Williams <nate@FreeBSD.ORG>
Received: (from nate@localhost)
	by freefall.freebsd.org (8.8.8/8.8.5) id MAA25250;
	Sat, 3 Oct 1998 12:17:12 -0700 (PDT)
Date: Sat, 3 Oct 1998 12:17:12 -0700 (PDT)
Message-Id: <199810031917.MAA25250@freefall.freebsd.org>
To: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject: cvs commit: src/contrib/sys/softupdates ffs_softdep.c
Sender: owner-cvs-all@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

nate        1998/10/03 12:17:12 PDT

  Modified files:
    contrib/sys/softupdates ffs_softdep.c 
  Log:
  Fix 'noatime' bug that was unrelated to use of noatime.
  
  The problem is caused when a directory block is compacted.  When this
  occurs, softdep_change_directoryentry_offset() is called to relocate each
  directory entry and adjust its matching diradd structure, if any, to match
  the new location of the entry.  The bug is that while
  softdep_change_directoryentry_offset() correctly adjusts the offsets of
  the diradd structures on the pd_diraddhd[] lists (which are not yet ready
  to be committed to disk), it fails to adjust the offsets of the diradd
  structures on the pd_pendinghd list (which are ready to be committed to
  disk).  This causes the dependency structures to be inconsistent with
  the buf contents.  Now, if the compaction has moved a directory entry to
  the same offset as one of the diradd structures on the pd_pendinghd list
  *and* a syscall is done that tries to remove this directory entry before
  this directory block has been written to disk (which would empty
  pd_pendinghd), a sanity check in newdirrem() will call panic() when it
  notices that the inode number in the entry that it is to be removed doesn't
  match the inode number in the diradd structure with that offset of that
  entry.
  
  Reviewed by:	Kirk McKusick <mckusick@McKusick.COM>
  Submitted by:	Don Lewis <Don.Lewis@tsc.tdk.com>
  
  Revision  Changes    Path
  1.15      +10 -1     src/contrib/sys/softupdates/ffs_softdep.c