search for: io_schedule

(vs format-changes branch) --- src/inc/ocfs_compat.h (revision 994) +++ src/inc/ocfs_compat.h (working copy) @@ -52,6 +70,8 @@ #define unlock_page(p) UnlockPage(p) #define Page_Uptodate(p) PageUptodate(p) +#define io_schedule schedule + #else /* LINUX_VERSION_CODE < 2.6 */ #define OCFS_GENERIC_SB_MEMBER(sb) ((sb)->s_fs_info) --- src/hash.c (revision 994) +++ src/hash.c (working copy) @@ -536,11 +536,7 @@ #endif if (!do_timeout) { set_task_state(tsk, TASK_UNINTERRUPTIBLE); -#if LINUX_VERSION_CODE >...

...0167] 0000000000012f00 ffff88000408c310 ffff8801fea937b0 ffff8801fefeea88 [ 1680.060175] 0000000000000002 ffffffff8113d0e0 ffff8801f103fbd0 ffff8801f103fc50 [ 1680.060183] Call Trace: [ 1680.060196] [<ffffffff8113d0e0>] ? wait_on_page_read+0x60/0x60 [ 1680.060204] [<ffffffff815114a9>] ? io_schedule+0x99/0x120 [ 1680.060210] [<ffffffff8113d0ea>] ? sleep_on_page+0xa/0x10 [ 1680.060216] [<ffffffff8151182c>] ? __wait_on_bit+0x5c/0x90 [ 1680.060222] [<ffffffff8113cedf>] ? wait_on_page_bit+0x7f/0x90 [ 1680.060231] [<ffffffff810a7e90>] ? autoremove_wake_function+0x30/0x30 [ 1...

...4] 0000000000015780 0000000000015780 ffff8800024ab170 ffff8800024ab468 [163440.613503] Call Trace: [163440.613520] [<ffffffff810e7e95>] ? kmem_cache_alloc+0x8c/0xf0 [163440.613528] [<ffffffff8102ddc0>] ? pvclock_clocksource_read+0x3a/0x8b [163440.613537] [<ffffffff8130b5f1>] ? io_schedule+0x73/0xb7 [163440.613546] [<ffffffff8118053b>] ? get_request_wait+0xf0/0x188 [163440.613553] [<ffffffff81065d0a>] ? autoremove_wake_function+0x0/0x2e [163440.613559] [<ffffffff811808ca>] ? __make_request+0x2f7/0x428 [163440.613565] [<ffffffff8117f0a7>] ? generic_make_req...

...0000000000012f00 ffff880004986a20 ffff8800ff3137b0 ffff8800ff80c260 [ 1920.052179] 0000000000000002 ffffffff811d7620 ffff8800047ebc80 ffff880002a5c7c0 [ 1920.052187] Call Trace: [ 1920.052199] [<ffffffff811d7620>] ? generic_block_bmap+0x50/0x50 [ 1920.052208] [<ffffffff815114a9>] ? io_schedule+0x99/0x120 [ 1920.052214] [<ffffffff811d762a>] ? sleep_on_buffer+0xa/0x10 [ 1920.052220] [<ffffffff8151182c>] ? __wait_on_bit+0x5c/0x90 [ 1920.052226] [<ffffffff811d7620>] ? generic_block_bmap+0x50/0x50 [ 1920.052232] [<ffffffff815118d7>] ? out_of_line_wait_on_bit+0x77/0...

Hi, Recently, I made a btrfs to use. And I met slowness problem. Trying to diag it. I found this: 1. dd if=/dev/zero of=test count=1024 bs=1MB This is fast, at about 25MB/s, and reasonable iowait. 2. dd if=/dev/zero of=test count=1 bs=1GB This is pretty slow, at about 1.5MB/s, and 90%+ iowait, constantly. May I know why it works like this? Thanks. -- To unsubscribe from this list: send the

...07 ffff81016471b820 ffff81021ac87040 0000e805f8d72d5b 0000000000002d53 ffff81016471ba08 0000000388055b77 Call Trace: [<ffffffff8006ecd9>] do_gettimeofday+0x40/0x90 [<ffffffff8005a412>] getnstimeofday+0x10/0x29 [<ffffffff80028bb2>] sync_page+0x0/0x43 [<ffffffff800637de>] io_schedule+0x3f/0x67 [<ffffffff80028bf0>] sync_page+0x3e/0x43 [<ffffffff80063922>] __wait_on_bit_lock+0x36/0x66 [<ffffffff8003f980>] __lock_page+0x5e/0x64 [<ffffffff800a34d5>] wake_bit_function+0x0/0x23 [<ffffffff8000c425>] do_generic_mapping_read+0x1df/0x359 [<ffffffff8...

Folks, The second release candidate for Xen 3.4.0 is available at http://xenbits.xensource.com/xen-unstable.hg, tagged as ''3.4.0-rc2''. Please test! -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

...08 0000000135c45c5c [902361.152418] Call Trace: [902361.152427] [<ffffffff8114238b>] ? elv_next_request+0x18f/0x1a3 [902361.152432] [<ffffffff810bfa3e>] ? sync_buffer+0x0/0x40 [902361.152436] [<ffffffff812f7090>] ? schedule+0x9/0x1d [902361.152439] [<ffffffff812f7107>] ? io_schedule+0x63/0xa5 [902361.152442] [<ffffffff810bfa3e>] ? sync_buffer+0x0/0x40 [902361.152445] [<ffffffff810bfa79>] ? sync_buffer+0x3b/0x40 [902361.152448] [<ffffffff812f7431>] ? __wait_on_bit+0x41/0x70 [902361.152452] [<ffffffff810bfa3e>] ? sync_buffer+0x0/0x40 [902361.152454]...

...ffff88005b819730 ffff88003c7bae60 ffff88005fd140c8 ffff88005feb2188 Jul 8 11:49:40 xback2 kernel: [74920.681032] Call Trace: Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810d80c7>] ? sync_page+0x0/0x4f Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8147439c>] io_schedule+0x47/0x62 Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810d8112>] sync_page+0x4b/0x4f Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8147482f>] __wait_on_bit_lock+0x46/0x8f Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810d8075>] __lock_page+0x6...

Hello, I have a 5.5TB Btrfs filesystem on top of a md-raid 5 device. Now if i run some file operations like find, i get these messages. kernel is 2.6.38.5-1 on arch linux May 5 14:15:12 mail kernel: [13559.089713] parent transid verify failed on 3062073683968 wanted 5181 found 5188 May 5 14:15:12 mail kernel: [13559.089834] parent transid verify failed on 3062073683968 wanted 5181 found 5188

...[<ffffffffa9b67c49>] schedule+0x29/0x70 [ 1085.193719] [<ffffffffa9b65721>] schedule_timeout+0x221/0x2d0 [ 1085.193724] [<ffffffffa942a621>] ? __switch_to+0x151/0x580 [ 1085.193730] [<ffffffffa9501052>] ? ktime_get_ts64+0x52/0xf0 [ 1085.193735] [<ffffffffa9b672ed>] io_schedule_timeout+0xad/0x130 [ 1085.193740] [<ffffffffa94c2886>] ? prepare_to_wait_exclusive+0x56/0x90 [ 1085.193744] [<ffffffffa9b67388>] io_schedule+0x18/0x20 [ 1085.193750] [<ffffffffa9743de3>] get_request+0x243/0x7d0 [ 1085.193756] [<ffffffffa977c401>] ? __radix_tree_create+0x...

...ty, I'm back as of today. I applied your patch series and did some testing... Removing a disk while reading from it mostly still ends up in hangs as of below: PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1" #0 [163f72e0] __schedule at 6aa22c #1 [163f7428] io_schedule at 6aab6c #2 [163f7448] sleep_on_page at 22cbb2 #3 [163f7460] __wait_on_bit at 6ab394 #4 [163f74b0] wait_on_page_bit at 22cef4 #5 [163f7508] filemap_fdatawait_range at 22d0a6 #6 [163f75e8] filemap_write_and_wait at 22de62 #7 [163f7618] fsync_bdev at 2dc5d8 #8 [163f7640] invalidate_par...

...ty, I'm back as of today. I applied your patch series and did some testing... Removing a disk while reading from it mostly still ends up in hangs as of below: PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1" #0 [163f72e0] __schedule at 6aa22c #1 [163f7428] io_schedule at 6aab6c #2 [163f7448] sleep_on_page at 22cbb2 #3 [163f7460] __wait_on_bit at 6ab394 #4 [163f74b0] wait_on_page_bit at 22cef4 #5 [163f7508] filemap_fdatawait_range at 22d0a6 #6 [163f75e8] filemap_write_and_wait at 22de62 #7 [163f7618] fsync_bdev at 2dc5d8 #8 [163f7640] invalidate_par...

...2 22:48:20 vmail kernel: [<ffffffff8006ecd9>] do_gettimeofday+0x40/0x90 May 2 22:48:20 vmail kernel: [<ffffffff8005a412>] getnstimeofday+0x10/0x29 May 2 22:48:20 vmail kernel: [<ffffffff8001558e>] sync_buffer+0x0/0x3f May 2 22:48:20 vmail kernel: [<ffffffff800637de>] io_schedule+0x3f/0x67 May 2 22:48:20 vmail kernel: [<ffffffff800155c9>] sync_buffer+0x3b/0x3f May 2 22:48:20 vmail kernel: [<ffffffff80063a0a>] __wait_on_bit+0x40/0x6e May 2 22:48:20 vmail kernel: [<ffffffff8001558e>] sync_buffer+0x0/0x3f May 2 22:48:20 vmail kernel: [<ffffffff8006...

A user has encountered a NULL pointer kernel oops in btrfs when encountering media errors. The problem has been identified as an unhandled NULL pointer returned from find_get_page(). This modification simply checks for a NULL page, and returns with an error if found (the extent_range_uptodate() function returns 1 on errors). After testing this patch, the user reported that the error with the

I have a 3 disk raid1 filesystem mounted with nodatacow. I have a folder in said filesystem with the ''C'' NOCOW & ''Z'' Not_Compressed flags set for good measure. I then copy in a large file and proceed to make random modifications. Filefrag shows no additional extents created, good so far. A big thank you to the those devs who got that working. However, after

...s_dev; -#endif atomic_t s_refcnt; struct buffer_head *s_bh; wait_queue_head_t s_wait; Index: src/inc/ocfs_compat.h =================================================================== --- src/inc/ocfs_compat.h (revision 1014) +++ src/inc/ocfs_compat.h (working copy) @@ -62,6 +62,11 @@ #define io_schedule schedule #endif +#define flush_scheduled_work flush_scheduled_tasks +#define work_struct tq_struct +#define INIT_WORK(w, f, d) INIT_TQUEUE(w, f, d) +#define schedule_work(w) schedule_task(w) + #ifdef HAVE_NPTL static inline void dequeue_signal_lock(struct task_struct *task,...

...ffff810c3f88f7e0 ffff810c3e843860 0011dd0b95e546c6 000000000000a1a4 ffff810c3f88f9c8 0000000400074c00 Call Trace: [<ffffffff8006ecd9>] do_gettimeofday+0x40/0x90 [<ffffffff8005a3ad>] getnstimeofday+0x10/0x29 [<ffffffff800155a2>] sync_buffer+0x0/0x3f [<ffffffff800637de>] io_schedule+0x3f/0x67 [<ffffffff800155dd>] sync_buffer+0x3b/0x3f [<ffffffff80063a0a>] __wait_on_bit+0x40/0x6e [<ffffffff800155a2>] sync_buffer+0x0/0x3f [<ffffffff80063aa4>] out_of_line_wait_on_bit+0x6c/0x78 [<ffffffff800a34d6>] wake_bit_function+0x0/0x23 [<ffffffff88033e5...

...ffff8800ccc3c530 [ 469.037801] ffff880090ecf818 ffff8800ccc3c530 ffff88011e254560 0000000000000002 [ 469.037807] Call Trace: [ 469.037814] [<ffffffff8112a830>] ? __lock_page+0x70/0x70 [ 469.037819] [<ffffffff8161e899>] schedule+0x29/0x70 [ 469.037824] [<ffffffff8161e96f>] io_schedule+0x8f/0xd0 [ 469.037831] [<ffffffff8112a83e>] sleep_on_page+0xe/0x20 [ 469.037838] [<ffffffff8161d130>] __wait_on_bit+0x60/0x90 [ 469.037845] [<ffffffff8112a970>] wait_on_page_bit+0x80/0x90 [ 469.037851] [<ffffffff8107f660>] ? autoremove_wake_function+0x50/0x50 [ 469...

Hi, all This version reworked on REQ_FLUSH and REQ_FUA support as suggested by Christoph and dropped the block core bits since Jens has picked them up. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%,