search for: log_do_checkpoint

Hello, I was wondering if we can get some help in resolving this bug. It was reported earlier and logged in bugme.osdl.org http://bugme.osdl.org/show_bug.cgi?id=4683 The problem is kernel oops at log_do_checkpoint() due to NULL buffer_head. This could be because of some race in journalling code for which I don't have much clue. There is kdump available for analysis as mentioned in the bugme. Thanks Maneesh -- Maneesh Soni Linux Technology Center, IBM India Software Labs, Bangalore, India email: manee...

A little bugfix delta. I don't believe there is a need for x86 users to upgrade. http://www.uow.edu.au/~andrewm/linux/ext3/ - Fix unaligned access on Alpha - Fix build with CONFIG_JBD=n - Speed up log_do_checkpoint() - significant benefits for journalled data mode. - Fix possible oops in log_do_checkpoint(). - Comment out unused journal_release_buffer().

...bhs[*batch_count] = bh; jbd_unlock_bh_state(bh); + transaction->t_chp_stats.cs_written++; (*batch_count)++; if (*batch_count == NR_BATCH) { __flush_batch(journal, bhs, batch_count); @@ -315,6 +317,8 @@ int log_do_checkpoint(journal_t *journal tid_t this_tid; transaction = journal->j_checkpoint_transactions; + if (transaction->t_chp_stats.cs_chp_time == 0) + transaction->t_chp_stats.cs_chp_time = CURRENT_MSECS; this_tid = tran...

Hi, We are running a server as an nfs head connect to a clariion, every couple of days we have our box fall over with the following msg in syslog. Has anyone had this happen to there boxen? rhel4 u4 May 8 12:23:52 ruchba kernel: Assertion failure in log_do_checkpoint() at fs/jbd/checkpoint.c:363: "drop_count != 0 || cleanup_ret != 0" May 8 12:23:52 ruchba kernel: ------------[ cut here ]------------ May 8 12:23:52 ruchba kernel: ------------[ cut here ]------------ May 8 12:23:52 ruchba kernel: kernel BUG at include/asm/spinlock.h:109! May 8 12:23...

...ogress when invalidate_buffers() is called, I get an oops: [[[LVM is in the process of calling PV_FLUSH ioctl => invalidate_buffers()]]] Attempt to refile free buffer Unable to handle kernel NULL pointer dereference at virtual address 00000000 <kdb stuff> refile_buffer cleanup_transaction log_do_checkpoint log_wait_for_space start_this_handle journal_start ext3_file_write do_readv_writev sys_write The oops is from "*(char *)0 = 0" added by the ext3 patch, but I take it that trying to refile a free buffer is fundamentally a bad thing. The oops is caused from __invalidate_buffers() calling...

This caused a crash on a 2.6.10-1.12_FC2smp kernel May 19 09:56:35 spf1 kernel: Assertion failure in log_do_checkpoint() at fs/jbd/checkpoint.c:361: "drop_count != 0 || cleanup_ret != 0" May 19 09:56:35 spf1 kernel: ------------[ cut here ]------------ May 19 09:56:37 spf1 kernel: kernel BUG at fs/jbd/checkpoint.c:361! May 19 09:56:37 spf1 kernel: invalid operand: 0000 [#1] May 19 09:56:37 spf1 kernel: S...

...d running pvscan (i.e. invalidate_buffers) repeatedly. At one point, I got several free buffers reported in cleanup_transaction. After that (this is the first time it happened) my kernel compile deadlocked and the kernel is stuck on: ext3_create journal_start start_this_handle log_wait_for_space log_do_checkpoint cleanup_transaction* __wake_up* The last 2 (*) functions appear and disappear from the KDB "bt" output, so I assume they are being called, but never finishing the transaction. I've added more debugging to determine which device's buffers are marked free (and compiling the kernel...

...t;] [<c0129067>] [<c01329bc>] [<c0129e40>] [<c012a08e>] [<c010a034>] Code: c6 05 00 00 00 00 00 e9 a6 00 00 00 90 80 7e 29 01 76 0a bb >>EIP; c012c25f <refile_buffer+17/d0> <===== Trace; c015f9bb <cleanup_transaction+12b/158> Trace; c015fbae <log_do_checkpoint+1c6/220> Trace; c015f86d <log_wait_for_space+8d/b0> Trace; c015c98b <start_this_handle+307/3a8> Trace; c015caa3 <journal_start+77/a0> Trace; c0152986 <ext3_notify_change+14a/360> Trace; c0120176 <do_generic_file_read+8d2/8e0> Trace; c0139638 <notify_change+40/64&...

...he disk device driver level a certain number of jiffies after the fs was mounted. This is to allow scripted testing of crash recovery. This facility has been extended to support two devices; one for the filesystem and one for the external journal device. - Accelerate an O(N^2) algorithm in log_do_checkpoint(). - Accelerate an O(N^2) algorithm in journal_commit_transaction(). - Rate-limit some error messages which can come out when we're hopelessly out of memory. - Honour __GFP_WAIT in journal_try_to_free_buffers(). The fs is supposed to perform synchronous writeout on the second pass of pa...

...19:58:32.000000000 +0900 @@ -848,7 +848,7 @@ extern int log_space_left (journal_t *); /* Called with journal locked */ extern tid_t log_start_commit (journal_t *, transaction_t *); -extern void log_wait_commit (journal_t *, tid_t); +extern int log_wait_commit (journal_t *, tid_t); extern int log_do_checkpoint (journal_t *, int); extern void log_wait_for_space(journal_t *, int nblocks); diff -Nru linux-2.4.29-pre3-bk2/mm/filemap.c linux-2.4.29-pre3-bk2_fix/mm/filemap.c --- linux-2.4.29-pre3-bk2/mm/filemap.c 2004-11-17 20:54:22.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/mm/filemap.c 2005-01-04 19:5...

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