ext3 htree brelse problems look to be fixed!

[James H. Cloos Jr.]

I just booted 2.5-bk current as of last night with the below patch¹
(which was recently posted to ext3-users) that un-static-ifies a 
struct dx_frame in namei.c.

I then did my best torture test for the brelse bug:  starting gnus
(3600+ nnmh folders² with a total of XXX messages; it does a readdir
on each of those folders) while doing bk consistancy checks in 2.5
and/or 2.4 kernel trees.  All while fetchmail+procmail+spamd processes
a stream of incoming mail.

That load had never failed to generate a brelse in the syslog; each
occurance of brelse in the syslog correlated to a short readdir.  In
gnus the short readdir would result in temporarily missing mail; in bk
the consistancy check would fail.  If the bk check was the result of a
pull, a manual bk resync would be required to fix the tree.  (Or one
could remove the RESYNC and PENDING dirs and re-pull.)

The bug did not occur during the torture test.  Even with three bk
checks in parallel (2.5 current, 2.4 current and a clone of a clone of
2.5 as of yesterday.)

I beleive (with this patch) htree is now ready for prime time.

-JimC

² one message per file in seq(1) order, ala old-style usenet spools

¹ the patch as posted by Andreas Dilger <[e-mail]> is:

===== namei.c 1.15 vs edited =====
--- 1.15/fs/ext3/namei.c        Wed Oct  2 01:24:11 2002
+++ edited/namei.c      Sun Mar  2 00:05:03 2003
@@ -530,7 +530,7 @@
        struct dx_hash_info hinfo;
        struct buffer_head *bh;
        struct ext3_dir_entry_2 *de, *top;
-       static struct dx_frame frames[2], *frame;
+       struct dx_frame frames[2], *frame;
        struct inode *dir;
        int block, err;
        int count = 0;