Date: Sat, 03 Oct 1998 13:07:36 -0400 From: Kirk McKusick <mckusick@McKusick.COM> To: Don Lewis <Don.Lewis@tsc.tdk.com> Cc: Terry Lambert <tlambert@primenet.com>, peter@netplex.com.au (Peter Wemm), bde@zeta.org.au, freebsd-current@FreeBSD.ORG, roberto@keltia.freenix.fr, Kevin Street <street@iname.com>, dg@root.com, julian@whistle.com Subject: Re: Softupdates panics Message-ID: <199810031707.KAA00360@flamingo.McKusick.COM> In-Reply-To: Your message of "Fri, 02 Oct 1998 00:35:00 PDT." <199810020735.AAA14928@salsa.gv.tsc.tdk.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Don,
I concur with your analysis of the problem and your fix. I am not
sure where the "official" copy of ffs_softdep.c is maintained on
freefall (I thought it was /usr/src/contrib/sys/softupdates, but
I find no files there). But where ever it is located, you should
put your fix into it (and let me know where that is).
I used to think that I was the only person that understood the
soft updates code. There is clearly a growing cadre of folks that
understand it at least as well as I do :-)
Kirk McKusick
=-=-=-=-=-=-=-=-=-=-=-=
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Date: Fri, 2 Oct 1998 00:35:00 -0700
In-Reply-To: Don Lewis <Don.Lewis@tsc.tdk.com>
"Re: Softupdates panics" (Sep 28, 12:35am)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Don Lewis <Don.Lewis@tsc.tdk.com>, Terry Lambert <tlambert@primenet.com>,
peter@netplex.com.au (Peter Wemm)
Subject: Re: Softupdates panics
Cc: bde@zeta.org.au, freebsd-current@FreeBSD.ORG, roberto@keltia.freenix.fr,
mckusick@McKusick.COM
On Sep 28, 12:35am, Don Lewis wrote:
} Subject: Re: Softupdates panics
} On Sep 27, 10:43pm, Terry Lambert wrote:
} } Subject: Re: Softupdates panics
} } > Had anybody got problems with softupdates that can be specifically
} } > attributed to the use of -noatime ?
} }
} } See the most recent stack traceback posted in this forum, and Don
} } Lewis' analysis.
}
} There was nothing in the traceback that leads me to believe this panic
} was caused by noatime. As a matter of fact, I got the same panic with
} a similar traceback earlier today and I'm not using noatime. My theory
} is that it's another directory locking bug. It's quite possible that
} using noatime may make it easier to trigger this bug.
I think I finally managed to track down the bug. It took me quite a while
because I had a very hard time triggering this panic, and the bug managed
to elude the traps I laid for it until this morning.
It turns out that my guess about the cause was incorrect. It is not a
directory locking bug. It also doesn't have anything to to with noatime,
though my guess that using noatime might cause the sanity check in
newdirrem() to catch the bug more often. As a matter of fact, the two
times I was able to provoke this panic, I was not using noatime. I was
never able to provoke this panic in my somewhat more limited testing with
noatime enabled.
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.
If noatime has any effect at all on this, it probably affects when
inodes are flushed to disk and indirectly the amount of time inconsistent
diradd structures remain on the pd_pendinghd list where newdirrem() might
stumble across them.
Here's the patch:
--- ffs_softdep.c.orig Sat Sep 26 08:12:39 1998
+++ ffs_softdep.c Thu Oct 1 23:58:14 1998
@@ -2230,6 +2230,15 @@
dap, da_pdlist);
break;
}
+ if (dap == NULL) {
+ for (dap = LIST_FIRST(&pagedep->pd_pendinghd);
+ dap; dap = LIST_NEXT(dap, da_pdlist)) {
+ if (dap->da_offset == oldoffset) {
+ dap->da_offset = newoffset;
+ break;
+ }
+ }
+ }
done:
bcopy(oldloc, newloc, entrysize);
FREE_LOCK(&lk);
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810031707.KAA00360>