search for: read_extent_buffer_pag

From: Liu Bo <liubo2009@cn.fujitsu.com> Fix return value to get from read_extent_buffer_pages(). Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> --- fs/btrfs/disk-io.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 6632e5c..35916d5 100644 --- a/fs/btrfs/di...

...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 NULL pointer oops was solved. However, there is still a remaining problem with a thread becoming stuck in wait_on_page_locked(page) in the read_extent_buffer_pages(...) function in extent_io.c for (i = start_i; i < num_pages; i++) { page = extent_buffer_page(eb, i); wait_on_page_locked(page); if (!PageUptodate(page)) ret = -EIO; } This patch leaves the issue with the lock...

...lags to extent_buffer flags. - Fix a race when triggering the read. - Fix a bug where only parts of the requested range where actually prefetched. The hit only when requesting parts of a tree, so the above numbers doesn''t change. Arne Jansen (6): btrfs: add an extra wait mode to read_extent_buffer_pages btrfs: add READAHEAD extent buffer flag btrfs: state information for readahead btrfs: initial readahead code and prototypes btrfs: hooks for readahead btrfs: test ioctl for readahead fs/btrfs/Makefile | 3 +- fs/btrfs/ctree.h | 13 + fs/btrfs/disk-io.c | 84 ++++- fs/b...

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

...The hit only when requesting parts of a tree, so the above numbers doesn''t change. Change from v2: - use rcu instead of transaction to protect root->node Change from v3: - rebased to current for-linus - in v3 patch 1 was missing Arne Jansen (7): btrfs: add an extra wait mode to read_extent_buffer_pages btrfs: add READAHEAD extent buffer flag btrfs: state information for readahead btrfs: initial readahead code and prototypes btrfs: hooks for readahead btrfs: test ioctl for readahead btrfs: use readahead API for scrub fs/btrfs/Makefile | 3 +- fs/btrfs/ctree.h | 13 + fs...

...99644] Pid: 3021, comm: btrfs-endio-wri Not tainted 3.7.0-rc4 #2 [ 2898.699646] Call Trace: [ 2898.699654] [<ffffffff8103cd4c>] ? warn_slowpath_common+0x76/0x8a [ 2898.699668] [<ffffffffa0192181>] ? btrfs_alloc_free_block+0xeb/0x2a0 [btrfs] [ 2898.699687] [<ffffffffa01b76fc>] ? read_extent_buffer_pages+0x1fb/0x247 [btrfs] [ 2898.699703] [<ffffffffa019ab85>] ? btree_readpage_end_io_hook+0x1d9/0x1d9 [btrfs] [ 2898.699715] [<ffffffffa0184461>] ? __btrfs_cow_block+0xf2/0x372 [btrfs] [ 2898.699726] [<ffffffffa018480d>] ? btrfs_cow_block+0xf1/0x141 [btrfs] [ 2898.699738] [<ff...

...10 > [ 605.116654] [<ffffffff81257241>] ? __extent_read_full_page+0x4e1/0x680 > [ 605.116820] [<ffffffff81255810>] ? end_bio_extent_readpage+0x0/0x210 > [ 605.116990] [<ffffffff8122c260>] ? btree_get_extent+0x0/0x1e0 > [ 605.117151] [<ffffffff81257660>] ? read_extent_buffer_pages+0x280/0x3c0 > [ 605.117320] [<ffffffff812d77ec>] ? radix_tree_insert+0x1bc/0x210 > [ 605.117488] [<ffffffff8122c260>] ? btree_get_extent+0x0/0x1e0 > [ 605.117651] [<ffffffff8122e945>] ? btree_read_extent_buffer_pages+0x55/0xb0 > [ 605.117820] [<ffffffff812...

...re''s some stuff I got from latencytop, not sure if would be helpful: 4969.1ms sys_mmap_pgoff syscall_call (chrome) 1139.9ms sync_page sync_page_killable __lock_page_killable generic_file_aio_read do_sync_read vfs_read sys_read sysenter_do_call (chrome) 431.9ms sync_page wait_on_page_bit read_extent_buffer_pages btree_read_extent_buffer_pages read_tree_block read_block_for_search btrfs_search_slot lookup_inline_extent_backref __btrfs_free_extent run_clustered_refs btrfs_run_delayed_refs btrfs_commit_transaction (btrfs) Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "u...

...gd@btrfs at Aug 3 05:09:33 ... kernel: [<e0dae63b>] ? btree_submit_bio_hook+0x0/0x3b [btrfs] Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [<e0dc0fc2>] ? submit_one_bio+0xdf/0x10c [btrfs] Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [<e0dc3854>] ? read_extent_buffer_pages+0x276/0x3c6 [btrfs] Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [<e0dc16cd>] ? add_lru+0x22/0x69 [btrfs] Message from syslogd@btrfs at Aug 3 05:09:33 ... kernel: [<e0dacbf7>] ? btree_read_extent_buffer_pages+0x3a/0x8e [btrfs] Message from syslogd@btrfs at Aug 3...

...;> lock_timer_base.clone.22+0x33/0x70 > >>> Feb 14 02:05:52 lupus kernel: [   70.058004]  [<ffffffff81305060>] > ? > >>> btree_get_extent+0x0/0x1c0 > >>> Feb 14 02:05:52 lupus kernel: [   70.058097]  [<ffffffff81330b21>] > ? > >>> read_extent_buffer_pages+0x2d1/0x470 > >>> Feb 14 02:05:52 lupus kernel: [   70.058191]  [<ffffffff81305060>] > ? > >>> btree_get_extent+0x0/0x1c0 > >>> Feb 14 02:05:52 lupus kernel: [   70.058283]  [<ffffffff8130674d>] > ? > >>> btree_read_extent_buffer_p...

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

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

On 06/21/2011 01:15 PM, Jan Stilow wrote: > Hello, > > Nirbheek Chauhan <nirbheek <at> gentoo.org> writes: >> [...] >> >> Every few minutes, (I guess) when applications do fsync (firefox, >> xchat, vim, etc), all applications that use fsync() hang for several >> seconds, and applications that use general IO suffer extreme >> slowdowns.

...k+0x11/0x20 Apr 30 14:25:46 btrfs kernel: [ 693.418863] [<ffffffff882e73a2>] :btrfs:btrfs_map_bio+0x52/0x180 Apr 30 14:25:46 btrfs kernel: [ 693.418946] [<ffffffff882e168f>] :btrfs:submit_one_bio+0xcf/0x120 Apr 30 14:25:46 btrfs kernel: [ 693.419029] [<ffffffff882e4d31>] :btrfs:read_extent_buffer_pages+0x2c1/0x3c0 Apr 30 14:25:46 btrfs kernel: [ 693.419111] [<ffffffff882cb900>] :btrfs:btree_get_extent+0x0/0x1d0 Apr 30 14:25:46 btrfs kernel: [ 693.419195] [<ffffffff882ca06d>] :btrfs:btree_read_extent_buffer_pages+0x4d/0x90 Apr 30 14:25:46 btrfs kernel: [ 693.419291] [<ffffffff8...

...\ + p = page_address(eb->pages[0]) + (eb->start & (PAGE_SIZE - 1)); \ p->member = cpu_to_le##bits(val); \ } diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index f633af8..00b80b7 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -373,6 +373,24 @@ static int btree_read_extent_buffer_pages(struct btrfs_root *root, WAIT_COMPLETE, btree_get_extent, mirror_num); if (!ret) { + /* + * I think that this is bad and should be moved + * into btree_readpage_end_io_hook(), but that + * it should apply to a single block at a time. + * That may be diff...

...97.413395] [<c013f692>] ? print_lock_contention_bug+0x11/0xb2 [ 297.413575] [<c04ad9b6>] ? btrfs_num_copies+0x20/0xba [ 297.413716] [<c07c6b0e>] ? _spin_unlock+0x2c/0x41 [ 297.413869] [<c04ada46>] ? btrfs_num_copies+0xb0/0xba [ 297.414007] [<c048f4b5>] ? btree_read_extent_buffer_pages+0x7f/0x95 [ 297.414204] [<c048f7f8>] read_tree_block+0x4c/0x58 [ 297.414339] [<c049264a>] open_ctree+0xa51/0xeff [ 297.414493] [<c01cc814>] ? disk_name+0x2a/0x6c [ 297.414624] [<c050d6e7>] ? strlcpy+0x17/0x48 [ 297.414770] [<c047b7e5>] btrfs_get_sb+0x20c/0x...

...] btree_submit_bio_hook+0x5a/0x100 [btrfs] [ 45.917188] [<f9ce2050>] ? btrfs_wq_submit_bio+0x170/0x170 [btrfs] [ 45.917188] [<f9d03c90>] submit_one_bio+0x80/0xb0 [btrfs] [ 45.917188] [<f9ce2050>] ? btrfs_wq_submit_bio+0x170/0x170 [btrfs] [ 45.917188] [<f9d0b848>] read_extent_buffer_pages+0x1f8/0x2b0 [btrfs] [ 45.917188] [<f9ce1af8>] btree_read_extent_buffer_pages.constprop.52+0xc8/0x140 [btrfs] [ 45.917188] [<f9cdff10>] ? run_one_async_done+0xd0/0xd0 [btrfs] [ 45.917188] [<f9ce23f7>] read_tree_block+0x47/0x50 [btrfs] [ 45.917188] [<f9ce5f5c>] o...

..._wait_on_bit+0x45/0x70 Oct 8 02:40:43 (none) kernel: [<c10bd7f0>] ? sync_page+0x0/0x40 Oct 8 02:40:43 (none) kernel: [<c10bda76>] wait_on_page_bit+0x86/0x90 Oct 8 02:40:43 (none) kernel: [<c105eb70>] ? wake_bit_function+0x0/0x60 Oct 8 02:40:43 (none) kernel: [<f89bde39>] read_extent_buffer_pages+0x489/0x4c0 [btrfs] Oct 8 02:40:43 (none) kernel: [<f8994c2b>] btree_read_extent_buffer_pages.clone.60+0x4b/0xb0 [btrfs] Oct 8 02:40:43 (none) kernel: [<f89939d0>] ? btree_get_extent+0x0/0x1c0 [btrfs] Oct 8 02:40:43 (none) kernel: [<f89959b7>] read_tree_block+0x47/0x60 [btrfs...

Hi all - Here''s my current error handling patchset, against 3.1-rc8. Almost all of this patchset is preparing for actual error handling. Before we start in on that work, I''m trying to reduce the surface we need to worry about. It turns out that there is a ton of code that returns an error code but never actually reports an error. The patchset has grown to 65 patches. 46 of them