Date: Thu, 29 Sep 2005 18:33:44 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: src-committers@FreeBSD.org Cc: cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/ufs/ffs ffs_softdep.c Message-ID: <200509300133.j8U1XiCt009131@gw.catspoiler.org> In-Reply-To: <200509292150.j8TLoQLs078259@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Sep, Don Lewis wrote: > 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 This may fix the "panic: handle_written_inodeblock: live inodedep" problem.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509300133.j8U1XiCt009131>