Kernel BUG in btree.c:514 when mounting
Hello!
After using nilfs2 for about 3 months (the version in Linux 2.6.31, not sure about the exact nilfs2 version number), I can no longer mount my root partition, as I immediately get a kernel BUG in btree.c:514. The process causing it is nilfs_cleanerd, though I suspect that might just be the first process to be executed. (Unfortunately, it is executed even if I use the "ro" option on the Linux command line -- why?!) It happens during a sys_open call. If the entire stack trace helps, I could post that, too.
In any case, it would be nice if, upon encountering a file system corruption of some sort, the nilfs implementation didn't BUG, but had an "errors=remount-ro" option like other file systems. Of course, that leaves open the question of how the file system got corrupted in the first place. The computer shut down cleanly yesterday.
Would it be possible to send the partition image to someone? The partition size is about 10 GB.
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi,
Quoted 7 lines · Sebastian Reichelt
Hello!
After using nilfs2 for about 3 months (the version in Linux 2.6.31, not sure about the exact nilfs2 version number), I can no longer mount my root partition, as I immediately get a kernel BUG in btree.c:514. The process causing it is
nilfs_cleanerd, though I suspect that might just be the first process to be executed.
The BUG tells that nilfs met a corrupted block during lookup of a btree.
Can you confirm which version of 2.6.31 kernel you were using?
I recommend you to use stable versions (I mean 2.6.31.12 or 2.6.32.8) or well-maintained distro kernels because some serious bugs are not yet fixed in the early 2.6.31 release.
Quoted 3 lines
(Unfortunately, it is executed even if I use the "ro" option on the Linux command line -- why?!) It happens during a
sys_opencall. If the entire stack trace helps, I could post that, too.
Sounds weird..
Quoted 3 lines
In any case, it would be nice if, upon encountering a file system corruption of some sort, the nilfs implementation didn't BUG, but had an "errors=remount-ro" option like other file systems.
That's a good point. The BUG_ON call was replaced in 2.6.33-rc1 to handle it as a filesystem error.
Although the "errors=remount-ro" option is not default in nilfs, I think it should be changed at some time.
Quoted 2 lines
Would it be possible to send the partition image to someone? The partition size is about 10 GB.
Unfortunately, the disk image is rarely-helpful from my experiences since it's hard to track the cause from a corrupted state.
Regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi,
thanks for your really quick reply.
Quoted 4 lines
The BUG tells that nilfs met a corrupted block during lookup of a btree.
Can you confirm which version of 2.6.31 kernel you were using?
The problem was, I had compiled the kernel on the same partition that is corrupted now. Anyway, by modifying the line in btree.c, I was able to recover most files, including the kernel tarball. (Though something like 1000 files are inaccessible.) I still cannot figure out the exact release number, though, because I can't find any place in the kernel source where it is written down. It was a kernel from the Debian testing distribution, downloaded on October 24. All files in the tarball are dated September 10. Does that help?
I had actually seen the post on www.nilfs.org about a file system corruption fix in nilfs 2.0.17, but when I downloaded the Linux source from Debian 3 weeks later, I thought for sure they would include the fix. I didn't know Debian testing was this far behind on critical bugfixes.
Quoted 5 lines
Quoted 3 lines
(Unfortunately, it is executed even if I use the "ro" option on the Linux command line -- why?!) It happens during a
sys_opencall. If the entire stack trace helps, I could post that, too.Sounds weird..
I still don't understand why nilfs_cleanerd was started even if the root fs was mounted read-only, but with the patched nilfs, it became clear that a library required by nilfs_cleanerd was among the files that were inaccessible, and that's why crashed right away. If I mount the file system later instead (as a non-root FS), the mount operation actually completes; the kernel just crashes when I try to access some files (with an unpatched/older nilfs such as the one in the current Ubuntu release).
Quoted 2 lines
That's a good point. The
BUG_ONcall was replaced in 2.6.33-rc1 to handle it as a filesystem error.
Oh, I didn't realize that.
Quoted 2 lines
Unfortunately, the disk image is rarely-helpful from my experiences since it's hard to track the cause from a corrupted state.
OK, I sort of expected that it wouldn't help. Then again, since there is no practical way of reproducing the bug, I thought the end result might be the only thing one can analyze to find the bug. Well, I'm glad I'm not a file system developer. :-)
Best regards,
Sebastian Reichelt
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi,
Quoted 9 lines · Sebastian Reichelt
Hi,
thanks for your really quick reply.
Quoted 4 lines
The BUG tells that nilfs met a corrupted block during lookup of a btree.
Can you confirm which version of 2.6.31 kernel you were using?
Quoted 9 lines
The problem was, I had compiled the kernel on the same partition that is corrupted now. Anyway, by modifying the line in
btree.c, I was able to recover most files, including the kernel tarball. (Though something like 1000 files are inaccessible.) I still cannot figure out the exact release number, though, because I can't find any place in the kernel source where it is written down. It was a kernel from the Debian testing distribution, downloaded on October 24. All files in the tarball are dated September 10. Does that help?
September 10 is the release date of 2.6.31 mainline kernel.
Hmm.. I guess your corruption is related to the missing bug-fixes. Could you try the latest debian kernel (i.e. 2.6.32-trunk) or the latest stable kernels ?
Quoted 5 lines
I had actually seen the post on www.nilfs.org about a file system corruption fix in nilfs 2.0.17, but when I downloaded the Linux source from Debian 3 weeks later, I thought for sure they would include the fix. I didn't know Debian testing was this far behind on critical bugfixes.
Linus merged the fixes soon and they were also sent to the stable kernel team at the same time. I heard that gentoo took the fixes relatively quickly. I don't know the Debian case, but it might take longer time.
Quoted 6 lines
Quoted 5 lines
Quoted 3 lines
(Unfortunately, it is executed even if I use the "ro" option on the Linux command line -- why?!) It happens during a
sys_opencall. If the entire stack trace helps, I could post that, too.Sounds weird..
Quoted 8 lines
I still don't understand why
nilfs_cleanerdwas started even if the root fs was mounted read-only, but with the patched nilfs, it became clear that a library required bynilfs_cleanerdwas among the files that were inaccessible, and that's why crashed right away. If I mount the file system later instead (as a non-root FS), the mount operation actually completes; the kernel just crashes when I try to access some files (with an unpatched/older nilfs such as the one in the current Ubuntu release).
Thanks for telling me the details. For the first issue, is there a possibility that the partition was remounted read/write?
Rw-remount also invokes cleanerd. Though mount.nilfs2 only runs it after the remount operation succeeded..
Quoted 7 lines
Quoted 2 lines
Unfortunately, the disk image is rarely-helpful from my experiences since it's hard to track the cause from a corrupted state.
OK, I sort of expected that it wouldn't help. Then again, since there is no practical way of reproducing the bug, I thought the end result might be the only thing one can analyze to find the bug. Well, I'm glad I'm not a file system developer. :-)
Since nilfs GC moves disk blocks, this makes such analysis harder than regular filesystems.
Fortunately, the recent nilfs builds are pretty stable, and this makes things easier than before ;)
Quoted 2 lines
Best regards,
Sebastian Reichelt
With regards,
Ryusuke Konishi
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html