Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Oct 2005 08:25:34 +0000 (UTC)
From:      Don Lewis <truckman@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/ufs/ffs ffs_softdep.c
Message-ID:  <200510020825.j928PYRA038705@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
truckman    2005-10-02 08:25:34 UTC

  FreeBSD src repository

  Modified files:        (Branch: RELENG_6)
    sys/ufs/ffs          ffs_softdep.c 
  Log:
  MFC ffs_softdep.c 1.185
  
  Original commit message:
  
    truckman    2005-09-29 21:50:26 UTC
  
     FreeBSD src repository
  
     Modified files:
       sys/ufs/ffs          ffs_softdep.c
     Log:
     After a rmdir()ed directory has been truncated, force an update of
     the directory's inode after queuing the dirrem that will decrement
     the parent directory's link count.  This will force the update of
     the parent directory's actual link to actually be scheduled.  Without
     this change the parent directory's actual link count would not be
     updated until ufs_inactive() cleared the inode of the newly removed
     directory, which might be deferred indefinitely.  ufs_inactive()
     will not be called as long as any process holds a reference to the
     removed directory, and ufs_inactive() will not clear the inode if
     the link count is non-zero, which could be the result of an earlier
     system crash.
  
     If a background fsck is run before the update of the parent directory's
     actual link count has been performed, or at least scheduled by
     putting the dirrem on the leaf directory's inodedep id_bufwait list,
     fsck will corrupt the file system by decrementing the parent
     directory's effective link count, which was previously correct
     because it already took the removal of the leaf directory into
     account, and setting the actual link count to the same value as the
     effective link count after the dangling, removed, leaf directory
     has been removed.  This happens because fsck acts based on the
     actual link count, which will be too high when fsck creates the
     file system snapshot that it references.
  
     This change has the fortunate side effect of more quickly cleaning
     up the large number dirrem structures that linger for an extended
     time after the removal of a large directory tree.  It also fixes a
     potential problem with the shutdown of the syncer thread timing out
     if the system is rebooted immediately after removing a large directory
     tree.
  
     Submitted by:   tegge
     MFC after:      3 days
  
     Revision  Changes    Path
     1.185     +2 -0      src/sys/ufs/ffs/ffs_softdep.c
  
  Submitted by:   tegge
  Approved by:    re (scottl)
  
  Revision   Changes    Path
  1.181.2.4  +2 -0      src/sys/ufs/ffs/ffs_softdep.c



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510020825.j928PYRA038705>