On Sun, Sep 29, 2002 at 07:46:57PM -0700, Ryan Cumming wrote:
> On September 29, 2002 01:16, Ryan Cumming wrote:
> > Case 1:
> > "Problem in HTREE directory inode 2 (/): bad block 3223649"
This turned out to actually be an e2fsprogs bug, not a kernel bug.
E2fsck was getting confused in some cases and interpreting a completely
empty directory block as a HTREE interior node, and thus incorrectly
flagging a valid HTREE directory as being corrupt. Your test case tends
to generate the empty directory blocks because it does a large amounts
of creates and deletes.
Anyway, let's try to synchronize on a common set of kernel patches and
userspace utilities, and see whether or not we've managed to get all of
the problems fixed.
For the kernel patches, I've created a patches against 2.4.19 and 2.5.39
that include the Andreas' kernel stack usage patch and Chrisl' empty
directory entry split patch, which can be found here:
http://thunk.org/tytso/linux/ext3-dxdir/patch-ext3-dxdir-2.4.19-3
http://thunk.org/tytso/linux/ext3-dxdir/patch-ext3-dxdir-2.5.39
In addition, I've released new e2fsprogs test release, which you can
obtain from sourceforge:
http://prdownloads.sourceforge.net/e2fsprogs/e2fsprogs-1.30-WIP-0930.tar.gz
With these code base, and using a freshly created filesystem, I haven't
been able to reproduce any problems using Ryan's fs-ream.c stress
tester. So I'm pretty confident about its stability, although there
might possibly be some race conditions lurking about under extreme load.
Ryan, you care to give it a go, and see what you can find?
- Ted
On Tue, Oct 01, 2002 at 12:09:43AM -0400, [email protected] wrote:
[...]
> Anyway, let's try to synchronize on a common set of kernel patches and
> userspace utilities, and see whether or not we've managed to get all of
> the problems fixed.
Sure, I'm willing (backed up my workstation completely, of course). I
first rebuilt 2.4.19 with your new patch applied on a ext3 fs with
dir_index disabled, built your new e2fsprogs WIP packages, and installed
them. Installed the new kernel. Turned on dir_index, and rebooted into
the new kernel.
[...]
> With these code base, and using a freshly created filesystem, I haven't
> been able to reproduce any problems using Ryan's fs-ream.c stress
> tester. So I'm pretty confident about its stability, although there
> might possibly be some race conditions lurking about under extreme load.
Good news: I haven't been able to replicate any of the corruption I was
seeing earlier with Galeon 1.2.6 and Mozilla 1.1 from Debian's unstable
branch. This corruption would occur pretty randomly but almost
immediately after starting Galeon, and it'd show up immediately in my
xconsole (I use xdm) in the form of some nasty EXT3 errors (as I noted
earlier).
I'll bang away with dump and bonnie[++] and see if I can make it spew.
;-)
Thanks again!
-Dan
--
Dan Chen [email protected]
GPG key: http://www.sh.nu/~crimsun/pubkey.gpg.asc