New set of code snapshots for ext3-dxdir (kernel and userspace)
Quoted 3 lines · Ryan Cumming
Quoted 2 lines · Ryan Cumming
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:
[...]
Quoted 3 lines
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.
[...]
Quoted 4 lines
With these code base, and using a freshly created filesystem, I haven't been able to reproduce any problems using Ryan's
fs-ream.cstress 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
Signature · 2 lines
Dan Chen [email protected] GPG key: www.sh.nu/~crimsun/pubkey.gpg.asc