similar to: kjournald hang on ext3 to ext3 copy

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

jbd2_journal_restart() would restart a handle. In this function, it calls start_this_handle(). Before calling start_this_handle()?subtract 1 from transaction->t_updates. If start_this_handle() succeeds, transaction->t_updates increases by 1 in it. But if start_this_handle() fails, transaction->t_updates does not increase. So, when commit the handle's transaction in

Description: Use schedule_timeout_{,un}interruptible() instead of set_current_state()/schedule_timeout() to reduce kernel size. Also use helper functions to convert between human time units and jiffies rather than constant HZ division to avoid rounding errors. Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> --- fs/cifs/cifsfs.c | 7 ++----- fs/cifs/connect.c

worker_loop() uses schedule_timeout() without setting state to STATE_(UN)INTERRUPTIBLE. As it is called in cycle without checking of pending signals, use schedule_timeout_uninterruptible(). Signed-off-by: Kulikov Vasiliy <segooon@gmail.com> --- fs/btrfs/async-thread.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/async-thread.c b/fs/btrfs/async-thread.c

Hello Everyone, Since rebooting my Centos 6.10 Openvz server "daisy" yesterday, I am getting horrible system performance.? /var/log/messages is full of HDIO_GET_IDENTITY failed for /dev/sdb.? The latest entries look like this: Apr 22 08:51:32 daisy kernel: [141224.655699] CT: 1005: stopped Apr 22 08:55:04 daisy ata_id[21513]: HDIO_GET_IDENTITY failed for '/dev/sdb' Apr 22

>> Hello Everyone, >> >> Since rebooting my Centos 6.10 Openvz server "daisy" yesterday, I am >> getting horrible system performance.? /var/log/messages is full of >> HDIO_GET_IDENTITY failed for /dev/sdb.? The latest entries look like >> this: >> >> Apr 22 08:51:32 daisy kernel: [141224.655699] CT: 1005: stopped >> Apr 22 08:55:04

Hi, everyone And we have the blocked cluster several times, and the log is always, we have to reboot all the node of the cluster to avoid it. Is there any patch that had fix this bug? [<ffffffff817539a5>] schedule_timeout+0x1e5/0x250 [<ffffffff81755a77>] wait_for_completion+0xa7/0x160 [<ffffffff8109c9b0>] ? try_to_wake_up+0x2c0/0x2c0 [<ffffffffa0564063>]

Hi, everyone And we have the blocked cluster several times, and the log is always, we have to reboot all the node of the cluster to avoid it. Is there any patch that had fix this bug? [<ffffffff817539a5>] schedule_timeout+0x1e5/0x250 [<ffffffff81755a77>] wait_for_completion+0xa7/0x160 [<ffffffff8109c9b0>] ? try_to_wake_up+0x2c0/0x2c0 [<ffffffffa0564063>]

Using fsdlm/ocfs2_controld.cman, I've rerun the test I've been having problems with on 2.6.30-rc1. After running for several minutes in the same directory on three nodes, the test hangs, and I collect the following information: bull-01 ------- 3053 S< [ocfs2dc] ocfs2_downconvert_thread 3054 S< [dlm_astd] dlm_astd 3055 S< [dlm_scand]

I have a server thats been running fine for a year or two lock up a few times recently, requiring power cycling. The /var/log/messages after a lockup last night is appended to this message. hardware is a pretty typical server, Supermicro X8DTE-F motherboard, dual Xeon X5650, 48GB ECC memory, LSI SAS 2008 for the boot disks, and LSI MegaRAID SAS 9261-8i for the data volume. Lots of 3TB

Hi, I setup two nodes, 192.168.20.20, and 192.168.20.21, The os is Ubuntu1204 with Kernel version 3.0: root at Server21:~# uname -a Linux Server21 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Server20 reboot for the disconnection with iSCSI SAN, so Server20 recovery resource locks for Server21. Server20: Feb 27 09:29:31 Server20 kernel:

Hi, I setup two nodes, 192.168.20.20, and 192.168.20.21, The os is Ubuntu1204 with Kernel version 3.0: root at Server21:~# uname -a Linux Server21 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Server20 reboot for the disconnection with iSCSI SAN, so Server20 recovery resource locks for Server21. Server20: Feb 27 09:29:31 Server20 kernel:

Hello, today I noticed the following on *only* one node: ----- cut here ----- Apr 29 11:01:18 node06 kernel: [2569440.616036] INFO: task ocfs2_wq:5214 blocked for more than 120 seconds. Apr 29 11:01:18 node06 kernel: [2569440.616056] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. Apr 29 11:01:18 node06 kernel: [2569440.616080] ocfs2_wq D

I am getting an odd situation when backing up a number of ext3 filesystems and was wondering if it could be caused by journalling. Over the space of a minute the load average will jump from 2 to over 40 and the system will be unresponsive for anywhere from 8 to 25 minutes. I am going to be trying a number of things, but was wondering if anyone could see the reason for the high load given the

Hello, I've attached the output from "sh scripts/ver_linux" per the bug reporting guidelines, and a diff of the file fs/jbd/transaction.c. At this point, I'm trying to hunt down why some system threads, which are executing the Lustre file system code, are taking an unexpectedly long time executing various ext3 file system functions. I added some debug code to these system

Hi all, and particularly Andrew and Stephen, I recently "upgraded' one of my NFS fileservers from (patched)2.4.18 to 2.4.23-pre7 (in order to resolve a HIMEM related memory pressure problem). Unfortunately I have experienced what appears to be a deadlock. The one I will describe was experienced while running 2.4.23-pre7, though I had a very similar problem in 2.4.22 (but

If we race with commit code setting i_transaction to NULL, we could possibly dereference it. Proper locking requires journal pointer (journal->j_list_lock) we don't have. So we have to change the prototype of the function so that filesystem passes us the journal pointer. Also add more detailed comment about why function does what it does how it should be used. Thanks to Dan Carpenter

Hi all, While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a number of splats in the block layer: * inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage in jbd2_trans_will_send_data_barrier * BUG: sleeping function called from invalid context at mm/mempool.c:320 * WARNING: CPU: 0 PID: 0 at block/blk.h:297 generic_make_request_checks+0x670/0x750 ... I've included the

Hi all, While fuzzing arm64/v4.16-rc2 with syzkaller, I simultaneously hit a number of splats in the block layer: * inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage in jbd2_trans_will_send_data_barrier * BUG: sleeping function called from invalid context at mm/mempool.c:320 * WARNING: CPU: 0 PID: 0 at block/blk.h:297 generic_make_request_checks+0x670/0x750 ... I've included the

From: Jan Kara <jack at suse.cz> If we race with commit code setting i_transaction to NULL, we could possibly dereference it. Proper locking requires the journal pointer (to access journal->j_list_lock), which we don't have. So we have to change the prototype of the function so that filesystem passes us the journal pointer. Also add a more detailed comment about why the function