On Tue, Dec 03, 2002 at 12:59:32AM +0100, Marc-Christian Petersen wrote:
> ext3_free_blocks: Freeing blocks not in datazone - block = 1530182
this is the interesting one. Did you run any unstable kernel/driver
software combination recently or maybe you got oopsed or crashes?
journaling sometime gives a false sense of reliability, you've to keep
in mind that unless you know why you had to reboot w/o a clean unmount
you should always force an e2fsck -f/reiserfsck in single user mode at
the next boot, no matter of journaling. If the machine crashed because
of a kernel oops or similar skipping the filesystemcheck at the very
next boot could left the fs corrupted for a long time until you notice
it possibly while running an unrelated kernel. So if you crashed
recently and you didn't run any e2fsck -f that could explain it. I doubt
there are corruption issues in my current tree (and even the UP deadlock
that I fixed couldn't explain the corruption, in this case [the UP
deadlock] I'm sure because I know what kind of side effect _this_ bug could
generate, for any other crash you cannot tell if e2fsck -f is needed
until/unless you know the details of the bug, and most of the time you
don't know the details of the bug at the time of the next reboot so
normally an e2fsck -f is always required after a kernel crash, this
can't be automated simply because if the kernel is crashed we can't
write to the superblock to notify e2fsck about it, so at the next boot
e2fsck will always think replying the log was enough).
Of course your problem could be explained by a bad cable or whatever
else hardware failure too. At the moment I doubt it's a problem in the
common code of my tree or mainline.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:15 EST