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 <adilger@clusterfs.com> 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;