Although my logs showed a different problem, ie, another ext3 function
in the kernel and with different error description: "rec_len is smaller
than minimal", maybe it is related.
I did a clean install of Jaunty and after 13 hours of uptime, it gave me
that error. It is worth mentioning that I was
As Dmitry Diskin pointed out, seems related:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/346691/comments/3
I don't know if that particular commit helps, but it points to
http://lkml.org/lkml/2008/11/14/121, where there is a script to stress test the
file system.
With kernels 2.6.28-11.4
I tested kernels 2.6.28-14.46 (jaunty-proposed) and 2.6.28.10 (mainline)
in a virtual machine and the problem still exists.
--
disk corruption ext3_free_blocks_sb: bit already cleared for block 232785
https://bugs.launchpad.net/bugs/209346
You received this bug notification because you are a mem
Kernel 2.6.28-02062810-generic does not fix the problem.
--
disk corruption ext3_free_blocks_sb: bit already cleared for block 232785
https://bugs.launchpad.net/bugs/209346
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
Yes, that was the kernel version indicated by "uname -a" after booting with
your kernel.
I can reproduce this easily on a virtual machine (64bits guest, haven't tried
32bits) using the script posted on http://lkml.org/lkml/2008/11/14/121 . Maybe
you can reproduce it in the same way?
--
disk co
If I understood correctly, disabling write back cache must be done on
the device (ie disk). However, the script I pointed in comment 19 tests
the filesystem creating it in RAM. However, I also tried mounting with
data=ordered instead of data=writeback (default), but it didn't affect
the results.
K
