search for: log_wait_commit

...:54:21.000000000 +0900 +++ linux-2.4.29-pre3-bk2_fix/fs/ext3/super.c 2005-01-04 19:58:32.000000000 +0900 @@ -1608,12 +1608,13 @@ static int ext3_sync_fs(struct super_block *sb) { + int err; tid_t target; sb->s_dirt = 0; target = log_start_commit(EXT3_SB(sb)->s_journal, NULL); - log_wait_commit(EXT3_SB(sb)->s_journal, target); - return 0; + err = log_wait_commit(EXT3_SB(sb)->s_journal, target); + return err; } /* diff -Nru linux-2.4.29-pre3-bk2/fs/jbd/checkpoint.c linux-2.4.29-pre3-bk2_fix/fs/jbd/checkpoint.c --- linux-2.4.29-pre3-bk2/fs/jbd/checkpoint.c 2002-11-29 08:53:15.00...

...000000 00000000 d1adeecc c041ec40 00000000 d1adeed8 f75d3e50 Apr 11 10:13:29 server kernel: Call Trace: Apr 11 10:13:29 server kernel: [<c041ec40>] __wake_up+0x2a/0x3d Apr 11 10:13:29 server kernel: [<c0436d23>] prepare_to_wait+0x24/0x46 Apr 11 10:13:29 server kernel: [<f885f1e2>] log_wait_commit+0x80/0xc7 [jbd] Apr 11 10:13:29 server kernel: [<c0436bd7>] autoremove_wake_function+0x0/0x2d Apr 11 10:13:29 server kernel: [<f885a661>] journal_stop+0x195/0x1ba [jbd] Apr 11 10:13:29 server kernel: [<c0495caa>] __writeback_single_inode+0x197/0x2a3 Apr 11 10:13:29 server kernel:...

...r is this the reason, why the umount hangs forever? [44825.302262] LustreError: Skipped 572 previous similar messages [44882.668079] Lustre: Failing over pfs1work-OST0026 [44882.674578] Lustre: *** setting obd pfs1work-OST0026 device ''unknown-block(9,7)'' read-only *** (gdb) l *(log_wait_commit+0xa3) 0xffffffff802e9f76 is in log_wait_commit (fs/jbd/journal.c:550). 545 while (tid_gt(tid, journal->j_commit_sequence)) { 546 jbd_debug(1, "JBD: want %d, j_commit_sequence=%d\n", 547 tid, journal->j_commit_sequ...

I have a system with many processes writing to a common data file using pwrite. These processes are each writing to existing blocks in the file, not changing the file size, and the file has no holes. When the processes get going, they seem to bottleneck at log_wait_common (according to ps alnx). That is, one process is uninterruptible in log_wait_common, the rest are uninterruptible in down.

...0 20743 1 20742 (NOTLB) ffff8107717ebd98 0000000000000086 0000000c717ebd18 0000000000000001 0000000400000000 000000000000000a ffff810b3acfb040 ffff810c400a4040 0011dd0835789020 00000000000161a0 ffff810b3acfb228 0000000400000092 Call Trace: [<ffffffff88036e55>] :jbd:log_wait_commit+0xa3/0xf5 [<ffffffff800a34a8>] autoremove_wake_function+0x0/0x2e [<ffffffff8803179a>] :jbd:journal_stop+0x1d3/0x203 [<ffffffff8002f96a>] __writeback_single_inode+0x1dd/0x31c [<ffffffff800f7454>] sync_inode+0x24/0x33 [<ffffffff8804c37e>] :ext3:ext3_sync_file+0xce/0...

...urnal, NULL); +} + +static int ext3_sync_fs(struct super_block *sb) +{ tid_t target; - if (down_trylock(&sb->s_lock) == 0) - BUG(); /* aviro detector */ sb->s_dirt = 0; target = log_start_commit(EXT3_SB(sb)->s_journal, NULL); - - if (do_sync_supers) { - unlock_super(sb); - log_wait_commit(EXT3_SB(sb)->s_journal, target); - lock_super(sb); - } + log_wait_commit(EXT3_SB(sb)->s_journal, target); + return 0; } /* _

...mmit_transaction) where it is waiting for t_updates to be 0. At this point, t_state is T_LOCKED, so presumably those nfsd threads above are waiting on kjournald. But what is kjournald really waiting for? My first though was the two nfsd threads in: nfsd Call Trace: [sleep_on+75/124] [log_wait_commit+74/136] [journal_stop+408/432] [journal_force_commit+78/128] [ext3_force_commit+66/112] [ext3_sync_file+128/144] [nfsd_sync_dir+49/72] [nfsd_unlink+455/480] [nfsd_proc_remove+122/140] [nfsd_dispatch+207/406] [svc_process+655/1264] [nfsd+566/944] [arch_kernel_thread+40/56] that are...

...000001786fc>] kthread+0xd8/0xe0 [<0000000000698fee>] kernel_thread_starter+0x6/0xc 2 locks held by kjournald/1984: ... and end up in hang situations ... PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1" #0 [1e2033e0] __schedule at 695ff2 #1 [1e203530] log_wait_commit at 3a28a6 #2 [1e2035a0] ext3_sync_fs at 328dea #3 [1e2035d8] sync_filesystem at 2c785c #4 [1e203600] fsync_bdev at 2d4650 #5 [1e203628] invalidate_partition at 3f80c8 #6 [1e203650] del_gendisk at 3f8f5c #7 [1e2036c8] virtblk_remove at 45e60e #8 [1e203700] virtio_dev_remove at 42d72e...

...000001786fc>] kthread+0xd8/0xe0 [<0000000000698fee>] kernel_thread_starter+0x6/0xc 2 locks held by kjournald/1984: ... and end up in hang situations ... PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1" #0 [1e2033e0] __schedule at 695ff2 #1 [1e203530] log_wait_commit at 3a28a6 #2 [1e2035a0] ext3_sync_fs at 328dea #3 [1e2035d8] sync_filesystem at 2c785c #4 [1e203600] fsync_bdev at 2d4650 #5 [1e203628] invalidate_partition at 3f80c8 #6 [1e203650] del_gendisk at 3f8f5c #7 [1e2036c8] virtblk_remove at 45e60e #8 [1e203700] virtio_dev_remove at 42d72e...

...e, say, 64KB worth > of write I/O. That I/O will just land in the page cache. Then, the > iozone process does an fsync which forces those I/Os to disk as > synchronous writes. Then, the file system's fsync method is invoked, > and for ext3/4, it calls log_start_commit followed by log_wait_commit. > Because those synchronous writes were forced out in the context of the > iozone process, CFQ will now idle on iozone's cfqq waiting for more I/O. > However, iozone's progress is gated by the journal thread, now. > > With this patch series applied (in addition to the two ot...

...ournal_create); EXPORT_SYMBOL(journal_load); EXPORT_SYMBOL(journal_destroy); -EXPORT_SYMBOL(journal_recover); EXPORT_SYMBOL(journal_update_superblock); EXPORT_SYMBOL(journal_abort); EXPORT_SYMBOL(journal_errno); -EXPORT_SYMBOL(journal_ack_err); EXPORT_SYMBOL(journal_clear_err); EXPORT_SYMBOL(log_wait_commit); EXPORT_SYMBOL(journal_start_commit); @@ -81,6 +78,7 @@ EXPORT_SYMBOL(journal_force_commit); static int journal_convert_superblock_v1(journal_t *, journal_superblock_t *); +static void __journal_abort_soft (journal_t *journal, int errno); /* * Helper function used to manage commit timeou...

...kernel_thread_starter+0x6/0xc >> 2 locks held by kjournald/1984: >> >> ... and end up in hang situations ... >> >> PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1" >> #0 [1e2033e0] __schedule at 695ff2 >> #1 [1e203530] log_wait_commit at 3a28a6 >> #2 [1e2035a0] ext3_sync_fs at 328dea >> #3 [1e2035d8] sync_filesystem at 2c785c >> #4 [1e203600] fsync_bdev at 2d4650 >> #5 [1e203628] invalidate_partition at 3f80c8 >> #6 [1e203650] del_gendisk at 3f8f5c >> #7 [1e2036c8] virtblk_re...

...kernel_thread_starter+0x6/0xc >> 2 locks held by kjournald/1984: >> >> ... and end up in hang situations ... >> >> PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1" >> #0 [1e2033e0] __schedule at 695ff2 >> #1 [1e203530] log_wait_commit at 3a28a6 >> #2 [1e2035a0] ext3_sync_fs at 328dea >> #3 [1e2035d8] sync_filesystem at 2c785c >> #4 [1e203600] fsync_bdev at 2d4650 >> #5 [1e203628] invalidate_partition at 3f80c8 >> #6 [1e203650] del_gendisk at 3f8f5c >> #7 [1e2036c8] virtblk_re...

...l.c, 202): kjournald: commit_sequence=83, commit_request=84 Oct 7 20:31:46 fargo kernel: (journal.c, 205): kjournald: OK, requests differ Oct 7 20:31:46 fargo kernel: (commit.c, 78): journal_commit_transaction: JBD: starting commit of transaction 84 Oct 7 20:31:46 fargo kernel: (journal.c, 544): log_wait_commit: JBD: want 84, j_commit_sequence=83 Thanks David Gómez "The question of whether computers can think is just like the question of whether submarines can swim." -- Edsger W. Dijkstra

...journal_destroy <Jun/27 03:57 pm>ext3: Unknown symbol journal_clear_err <Jun/27 03:57 pm>ext3: Unknown symbol journal_stop <Jun/27 03:57 pm>ext3: Unknown symbol journal_init_inode <Jun/27 03:57 pm>ext3: Unknown symbol journal_start <Jun/27 03:57 pm>ext3: Unknown symbol log_wait_commit <Jun/27 03:57 pm>ext3: Unknown symbol journal_release_buffer <Jun/27 03:57 pm>ext3: Unknown symbol journal_check_available_features <Jun/27 03:57 pm>ext3: Unknown symbol journal_abort <Jun/27 03:57 pm>ext3: Unknown symbol journal_restart <Jun/27 03:57 pm>insmod: error...

...; [<0000000000698fee>] kernel_thread_starter+0x6/0xc > 2 locks held by kjournald/1984: > > ... and end up in hang situations ... > > PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1" > #0 [1e2033e0] __schedule at 695ff2 > #1 [1e203530] log_wait_commit at 3a28a6 > #2 [1e2035a0] ext3_sync_fs at 328dea > #3 [1e2035d8] sync_filesystem at 2c785c > #4 [1e203600] fsync_bdev at 2d4650 > #5 [1e203628] invalidate_partition at 3f80c8 > #6 [1e203650] del_gendisk at 3f8f5c > #7 [1e2036c8] virtblk_remove at 45e60e > #8 [1e20...

I have ext3 0.0.6b + 2.2.19 and cannot get ext3 to compile as a module. If I try to modularize it, or turn in off completely, the kernel build fails. Is there an easy fix for this, or is there something that I am missing? Thanks. Peter

ocfs2 currently uses the Journaled Block Device (JBD) for its journaling. This is a very stable and tested codebase. However, JBD is limited by architecture to 32bit block numbers. This means an ocfs2 filesystem is limited to 2^32 blocks. With a 4K blocksize, that's 16TB. People want larger volumes. Fortunately, there is now JBD2. JBD2 adds 64bit block number support and some other

Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. When an active virtio block device is hot-unplugged from a KVM guest, affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. Additionally a potential

Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th. When an active virtio block device is hot-unplugged from a KVM guest, affected guest user applications are not aware of any errors that occur due to the lost device. This patch-set adds code to avoid further request queueing when a lost block device is detected, resulting in appropriate error info. Additionally a potential