Add a ffs_blkfree panic todo list item: we believe it may be fixed,

but have had at least one panic report since the fix was committed,
and so need to watch this carefully.  Include a note that this is
considered a "show-stopper" for 5.1-BETA until resolved.
This commit is contained in:
Robert Watson 2003-05-04 16:29:00 +00:00
parent 6a17cb18d4
commit b86bc06c56
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/www/; revision=16788

View file

@ -1,7 +1,7 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" [
<!ENTITY base CDATA "../..">
<!ENTITY email 'freebsd-qa'>
<!ENTITY date "$FreeBSD: www/en/releases/5.1R/todo.sgml,v 1.28 2003/05/03 08:21:18 scottl Exp $">
<!ENTITY date "$FreeBSD: www/en/releases/5.1R/todo.sgml,v 1.29 2003/05/03 23:06:15 bmah Exp $">
<!ENTITY title "FreeBSD 5.1 Open Issues">
<!ENTITY % includes SYSTEM "../../includes.sgml"> %includes;
<!ENTITY % developers SYSTEM "../../developers.sgml"> %developers;
@ -106,6 +106,25 @@
are currently being tested that halve this locking cost when
dynamic policies are not loaded.</td>
</tr>
<tr>
<td>panic: ffs_blkfree</td>
<td>In progress</td>
<td>--</td>
<td>Starting in late April, reports of a new UFS panic,
"panic: ffs_blkfree: freeing free frag" began to pop up with
a high frequency in some environments. It appears not to
have been the direct result of a commit to UFS itself,
pointing the finger at other recent changes (VM locking and
fixes, proc locking, ...). While some changes to VM have
been made that were intended to fix this problem (and appear
to have for several cases), there's at least one remaining
report of a problem that may or may not result from
persisting un-fsck'd file systems. This is a show stopper
bug that will prevent a transition to 5.1-BETA unless
resolved.</td>
</tr>
</table>
<h3>Desired Features for 5.1-RELEASE</h3>