| Summary: | kernel BUG at fs/ext3/namei.c:384! invalid opcode: 0000 [#1] | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Dekel Amrani <dekela> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | VERIFIED NEEDINFO | ||
| Severity: | normal | CC: | duaneg |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| URL: | http://bugzilla.kernel.org/show_bug.cgi?id=6628 | ||
| Whiteboard: | linux-2.6.22.9 | ||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
ext3-gracefully-handle-corrupt-htree.patch
fuzz_dir_index.c |
||
|
Description
Dekel Amrani
2007-06-26 01:38:18 UTC
Question: Do you dual boot? Do you use Ext2IFS drivers in windows to access this hard drive? Trying to determine if this is a similar issue I found on the net. Was this a one-time error or is it reproducible? (In reply to comment #2) > Was this a one-time error or is it reproducible? > Reproducible.. After ever boot. And yes I do use ext driver in windows. And I dual boot.. Could it be corrupted fs? Dekel Oh and by the way its: 2.6.21-r2 Here's a similar bug from the Ubuntu folks: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/109177 They reporter points the finger out a corrupt file system, but they do not offer any solution. Another (maybe related?) reference from upstream kernel bugzilla, but also with no solution: http://bugzilla.kernel.org/show_bug.cgi?id=6628 Please post "tune2fs -l /dev/sda1" output I think I've managed to fix this. The ext3 code already has provision for falling back to a linear scan if it detects a corrupt directory index, so all that is required is for the dx_probe function to fail and return the appropriate error instead of asserting. I'll attach the proposed patch, source code for a utility to reproduce the problem, and a recipe for doing so. Please let me know if it stops the BUG for you. Note that you will still see a warning in your log about the corruption. The FS can be fixed by running "/sbin/fsck.ext3 -f" on it. I'll send this upstream once I have confirmation that it works for someone else. Created attachment 125707 [details, diff]
ext3-gracefully-handle-corrupt-htree.patch
Fall back to linear directory scan instead of asserting if a corrupt directory index is found
Created attachment 125708 [details]
fuzz_dir_index.c
Source code for a utility to corrupt a directory hash. Run it with -c or -e to corrupt the entry count and/or entry limit respectively. Run it with -L1 to corrupt a (randomly selected) indirect index or -L0 (default) to corrupt the directory root.
DO NOT USE THIS ON A FILESYSTEM YOU CARE ABOUT!
Corruption can be corrected by running "/sbin/fsck.ext3 -f <fs>".
To create a test filesystem do the following: # Create an empty FS dd if=/dev/zero of=test-fs.ext3 count=100 bs=1M /sbin/mkfs.ext3 -F -m0 -b1024 -i1024 -j -Osparse_super,dir_index test-fs.ext3 # Fill a directory with lots of files mkdir mnt mount -oloop test-fs.ext3 mnt mkdir mnt/a for n in `seq 0 100000` ; do touch mnt/a/file-$n ; done umount mnt rmdir mnt # Ensure it uses hash indexed directories /sbin/e2fsck -f -v -D test-fs.ext3 Dekel, have you had time to try Duane's patch? See comment #10. Please reopen if you have tested the patch. FYI: something very similar to the patch here has just been accepted into the -mm tree. It should make its way into mainline soon. Not sure whether it will be going into .23 or .24, though. The final version of the patch is here: http://marc.info/?l=linux-kernel&m=118947590719691 The patch has been added to 2.6.22.9 and 2.6.23. |
