similar to: transaction->t_forget == NULL assertion failure with data=journal

Hi, A couple of our important servers, both running FC4 but one i386 and one x86_64, have been crashing recently. They both are running ext3 data=journal with large external journals and high commit intervals. Both machines use the gdth driver for their hardware RAID sets, if that's of any use. I think the hardware is good in both cases. I hope someone finds this data useful enough to be

Hi all, One of our mx servers started misbehaving today (postfix would timeout internally, load rising) and after I tried to reboot it, I got this: Assertion failure in __journal_drop_transaction() at fs/jbd/checkpoint.c:613: "transaction->t_forget == NULL" ------------[ cut here ]------------ kernel BUG at fs/jbd/checkpoint.c:613! invalid operand: 0000 [#1] PREEMPT SMP Modules

Hi Ext3! I'm running about 30 dedicated MySQL machines under quite decent loads, and they are occassionally crashing. I've been logging console messages recently in an effort to find the cause, and some appear to be related to I perused your lists and found the message I'm replying to. If you don't mind, I've included messages and ksymoops from two crashes that I had

Hello all, Last night a server of mine went belly up with my remote log server telling me this log entry: kernel: Assertion failure in __journal_drop_transaction() at fs/jbd/checkpoint.c:615: "transaction->t_forget == NULL" During this time, we had high email loads and I have my 2 /var/spool/postfix_1 and /var/spool/postfix_2 partitions mounted with "data=journal" option.

The following 6 patches cleanup the jbd code and kill about 200 lines. First of 4 patches can apply to 2.6.13-git8 and 2.6.13-mm2. The rest of them can apply to 2.6.13-mm2. fs/jbd/checkpoint.c | 179 +++++++++++-------------------------------- fs/jbd/commit.c | 101 ++++++++++-------------- fs/jbd/journal.c | 11 +- fs/jbd/revoke.c | 158

While writing a file to an ext3 filesystem, i get some drive errors on the console. I guess is a drive/ide related problem more that a ext3 one, but anyway the debug output is here if you want to take a look. And, by the way, what means that DRQ thing?? Oct 7 20:31:36 fargo kernel: (journal.c, 218): kjournald: kjournald wakes Oct 7 20:31:36 fargo kernel: (journal.c, 202): kjournald:

Hi, More than 1000''s of classes and filters gets created/deleted in run time. Are we doing it correctly( as our requirement is such). Since few days we are facing lots of problems, like the server gets hanged, we get some junk messages in our logs. we have to reboot our server every now and then. What is the max limit of classes/filters can be created. we are using redhat 7.3.

Hi, as I mentioned in earlier mail to ext3-users I have been getting some corruption on an ext3 filesystem that has been serving NFS. I am now confident that I fully understand the problem and have a patch. It only affects data=journal mode and I wonder if it might also be the cause of the corruption noted by a number of people on linux-kernel. First I will explain the problem. Then display

This version fixes three bugs in the 2nd patch of this series that caused kernel BUG when the system was under race. We weren't accounting with t_oustanding_credits correctly, and there were race conditions caused by the fact the I had overlooked the fact that __jbd2_log_wait_for_space() and jbd2_get_transaction() requires j_state_lock to be write locked. Theodore Ts'o (3): jbd2: Use