* btrfs hang in flush-btrfs-5
@ 2011-07-08 10:58 Jeremy Sanders
2011-07-09 13:13 ` Jeremy Sanders
2011-07-11 11:40 ` Jeremy Sanders
0 siblings, 2 replies; 6+ messages in thread
From: Jeremy Sanders @ 2011-07-08 10:58 UTC (permalink / raw)
To: linux-btrfs
Hi - I'm trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora kernel).
I'm just doing a tar-to-tar copy onto the file system with compress-
force=zlib. Here are some traces of the stuck processes.
flush-btrfs-5 seems to be stuck:
Jul 8 11:49:40 xback2 kernel: [74920.681032] flush-btrfs-5 D
ffff88003c7bae60 0 11712 2 0x00000080
Jul 8 11:49:40 xback2 kernel: [74920.681032] ffff88001842f750
0000000000000046 000000000000ce5a ffff88003c7bae60
Jul 8 11:49:40 xback2 kernel: [74920.681032] ffff88001842ffd8
ffff88001842ffd8 0000000000013840 0000000000013840
Jul 8 11:49:40 xback2 kernel: [74920.681032] 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+0x66/0x68
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8106f2ab>] ?
wake_bit_function+0x0/0x31
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa0430cf9>]
lock_page+0x3a/0x3e [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa04310a6>]
lock_delalloc_pages+0xad/0x1af [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa0432f7c>]
find_lock_delalloc_range.constprop.9+0xc8/0x1ba [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa0433866>]
__extent_writepage+0x15c/0x582 [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8122d488>] ?
radix_tree_gang_lookup_tag_slot+0x81/0xa2
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff81474867>] ?
__wait_on_bit_lock+0x7e/0x8f
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa0433dd0>]
extent_write_cache_pages.constprop.6+0x144/0x28f [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff81475f0e>] ?
common_interrupt+0xe/0x13
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa043417b>]
extent_writepages+0x3f/0x50 [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8113e27a>] ?
list_move+0x29/0x30
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa041af1d>] ?
btrfs_get_extent+0x0/0x74f [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa041ade3>]
btrfs_writepages+0x28/0x2a [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810e05d5>]
do_writepages+0x21/0x2a
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8113e386>]
writeback_single_inode+0x96/0x194
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8113e6db>]
writeback_sb_inodes+0xa1/0x12b
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8113f4f0>]
writeback_inodes_wb+0x163/0x175
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8113f741>]
wb_writeback+0x23f/0x35a
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff81080b7b>] ?
arch_local_irq_save+0x15/0x1b
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8113f8e2>]
wb_do_writeback+0x86/0x19d
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff81060bb4>] ?
process_timeout+0x0/0x10
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8113fa81>]
bdi_writeback_thread+0x88/0x1e5
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8113f9f9>] ?
bdi_writeback_thread+0x0/0x1e5
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8106ebaf>]
kthread+0x84/0x8c
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8100a9e4>]
kernel_thread_helper+0x4/0x10
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8106eb2b>] ?
kthread+0x0/0x8c
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8100a9e0>] ?
kernel_thread_helper+0x0/0x10
Here is the state of the tar which is stuck in D:
Jul 8 11:49:40 xback2 kernel: [74920.681032] tar D
ffff88005fc0f440 0 13171 11702 0x00000084
Jul 8 11:49:40 xback2 kernel: [74920.681032] ffff88003aa5b468
0000000000000086 0000000000000001 ffff880059bdc590
Jul 8 11:49:40 xback2 kernel: [74920.681032] ffff88003aa5bfd8
ffff88003aa5bfd8 0000000000013840 0000000000013840
Jul 8 11:49:40 xback2 kernel: [74920.681032] ffff88005ba1c590
ffff880059bdc590 ffff88005fc140c8 000000015feb58a8
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+0x66/0x68
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8106f2ab>] ?
wake_bit_function+0x0/0x31
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8111493a>]
lock_page+0x3a/0x3e
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8111535f>]
move_to_new_page+0x123/0x1a1
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff81115732>]
migrate_pages+0x246/0x38c
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8110b787>] ?
compaction_alloc+0x0/0x2a3
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810ecabe>] ?
zone_page_state_add+0x2f/0x34
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8110bf73>]
compact_zone+0x3e7/0x5ca
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8110c2e5>]
compact_zone_order+0x94/0x9f
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8110c381>]
try_to_compact_pages+0x91/0xe3
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8146e867>]
__alloc_pages_direct_compact+0xa7/0x16d
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810deea3>]
__alloc_pages_nodemask+0x46a/0x77f
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff81108755>]
alloc_pages_current+0xbe/0xd8
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8111c7aa>] ?
__mem_cgroup_try_charge+0x111/0x480
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8110f902>]
alloc_slab_page+0x1c/0x4d
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff81110f4c>]
new_slab+0x50/0x199
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8146f999>]
__slab_alloc+0x24a/0x328
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8122cc1d>] ?
radix_tree_preload+0x31/0x81
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8122cc1d>] ?
radix_tree_preload+0x31/0x81
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8111173e>]
kmem_cache_alloc+0x77/0x105
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8122cc1d>]
radix_tree_preload+0x31/0x81
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810d89cd>]
add_to_page_cache_locked+0x56/0x118
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810d8ab9>]
add_to_page_cache_lru+0x2a/0x58
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff810d8d61>]
find_or_create_page+0x5a/0x8a
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa0423620>]
prepare_pages+0xd3/0x2e7 [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa040aad7>] ?
btrfs_delalloc_reserve_metadata+0xf9/0x128 [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa0423ca6>]
btrfs_file_aio_write+0x472/0x7f1 [btrfs]
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff811346ef>] ?
touch_atime+0x116/0x131
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8112104b>]
do_sync_write+0xbf/0xff
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8114db7b>] ?
fsnotify+0x1eb/0x217
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff811e8102>] ?
security_file_permission+0x2e/0x33
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff81121436>] ?
rw_verify_area+0xb0/0xcd
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff811216c1>]
vfs_write+0xac/0xf3
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff811218b0>]
sys_write+0x4a/0x6e
Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff81009bc2>]
system_call_fastpath+0x16/0x1b
The system has 1.5GB RAM, is x86-64 and the processor is an Athlon X2 4600+.
The btrfs volume is currently on an linux software raid md device.
I'm also concerned about the space usage. Does "btrfs filesystem df" show
the uncompressed or compressed space?
The space used reported there is similar to the uncompressed space used for
a ZFS copy of the data (which achives a compression ratio of x1.59).
Jeremy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs hang in flush-btrfs-5
2011-07-08 10:58 btrfs hang in flush-btrfs-5 Jeremy Sanders
@ 2011-07-09 13:13 ` Jeremy Sanders
2011-07-11 11:40 ` Jeremy Sanders
1 sibling, 0 replies; 6+ messages in thread
From: Jeremy Sanders @ 2011-07-09 13:13 UTC (permalink / raw)
To: linux-btrfs
Jeremy Sanders wrote:
> Hi - I'm trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora
> kernel). I'm just doing a tar-to-tar copy onto the file system with
> compress- force=zlib. Here are some traces of the stuck processes.
Does anyone have any idea what caused this? Is it fixed in a recent btrfs?
Thanks
Jeremy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs hang in flush-btrfs-5
2011-07-08 10:58 btrfs hang in flush-btrfs-5 Jeremy Sanders
2011-07-09 13:13 ` Jeremy Sanders
@ 2011-07-11 11:40 ` Jeremy Sanders
2011-07-11 14:30 ` Josef Bacik
1 sibling, 1 reply; 6+ messages in thread
From: Jeremy Sanders @ 2011-07-11 11:40 UTC (permalink / raw)
To: linux-btrfs
Jeremy Sanders wrote:
> Hi - I'm trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora
> kernel). I'm just doing a tar-to-tar copy onto the file system with
> compress- force=zlib. Here are some traces of the stuck processes.
I've managed to reproduce the hang using the latest btrfs from the
repository. I had to remove some of the tracing lines to get it to compile
under 2.6.38.8 and an ioctl which wasn't defined. Here is is where it is
stuck:
[ 8390.923737] flush-btrfs-4 D ffff88005aeef480 0 2965 2
0x00000080
[ 8390.923907] ffff8800026cb720 0000000000000046 ffff8800026cb690
ffffffff00000001
[ 8390.924037] 0000000000013840 0000000000013840 0000000000013840
ffff88005931ae60
[ 8390.924037] 0000000000013840 ffff8800026cbfd8 0000000000013840
0000000000013840
[ 8390.924037] Call Trace:
[ 8390.924037] [<ffffffff810e03e7>] ? sync_page+0x0/0x4d
[ 8390.924037] [<ffffffff8148ad2f>] io_schedule+0x47/0x62
[ 8390.924037] [<ffffffff810e0430>] sync_page+0x49/0x4d
[ 8390.924037] [<ffffffff8148b1cc>] __wait_on_bit_lock+0x46/0x8f
[ 8390.924037] [<ffffffff810e038c>] __lock_page+0x66/0x6d
[ 8390.924037] [<ffffffff8107374c>] ? wake_bit_function+0x0/0x31
[ 8390.924037] [<ffffffff8104767a>] ? should_resched+0xe/0x2e
[ 8390.924037] [<ffffffffa0541727>] lock_page+0x3d/0x41 [btrfs]
[ 8390.924037] [<ffffffffa0541d22>] lock_delalloc_pages+0xb7/0x1a2 [btrfs]
[ 8390.924037] [<ffffffffa05439b9>]
find_lock_delalloc_range.clone.18+0xd9/0x1cb [btrfs]
[ 8390.924037] [<ffffffff8123fe95>] ? __lookup_tag+0xb9/0x123
[ 8390.924037] [<ffffffffa05442ce>] __extent_writepage+0x156/0x561 [btrfs]
[ 8390.924037] [<ffffffff8123ff80>] ?
radix_tree_gang_lookup_tag_slot+0x81/0xa2
[ 8390.924037] [<ffffffff810e00d5>] ? find_get_pages_tag+0x6f/0xd5
[ 8390.924037] [<ffffffffa054480d>]
extent_write_cache_pages.clone.9.clone.16+0x134/0x2a1 [btrfs]
[ 8390.924037] [<ffffffffa0544bea>] extent_writepages+0x47/0x5c [btrfs]
[ 8390.924037] [<ffffffffa052b78c>] ? btrfs_get_extent+0x0/0x77f [btrfs]
[ 8390.924037] [<ffffffff81073620>] ? bit_waitqueue+0x17/0xa9
[ 8390.924037] [<ffffffffa052a980>] btrfs_writepages+0x27/0x29 [btrfs]
[ 8390.924037] [<ffffffff810e8a0e>] do_writepages+0x21/0x2a
[ 8390.924037] [<ffffffff81149aa0>] writeback_single_inode+0x9c/0x19b
[ 8390.924037] [<ffffffff81149d9b>] writeback_sb_inodes+0xa1/0x12b
[ 8390.924037] [<ffffffff8114a7bc>] writeback_inodes_wb+0x163/0x175
[ 8390.924037] [<ffffffff8114aa1d>] wb_writeback+0x24f/0x368
[ 8390.924037] [<ffffffff8114acb9>] wb_do_writeback+0x183/0x19e
[ 8390.924037] [<ffffffff8148b0f6>] ? schedule_timeout+0xb3/0xe3
[ 8390.924037] [<ffffffff8114ad5c>] bdi_writeback_thread+0x88/0x205
[ 8390.924037] [<ffffffff8114acd4>] ? bdi_writeback_thread+0x0/0x205
[ 8390.924037] [<ffffffff8107326e>] kthread+0x82/0x8a
[ 8390.924037] [<ffffffff8100ba64>] kernel_thread_helper+0x4/0x10
[ 8390.924037] [<ffffffff810731ec>] ? kthread+0x0/0x8a
[ 8390.924037] [<ffffffff8100ba60>] ? kernel_thread_helper+0x0/0x10
[ 8390.933163] tar D ffff880019053478 0 4195 2953
0x00000084
[ 8390.933163] ffff8800190533d8 0000000000000086 ffffffff813b9878
0000000000000010
[ 8390.933163] 0000000000013840 0000000000013840 0000000000013840
ffff880045beae60
[ 8390.933163] 0000000000013840 ffff880019053fd8 0000000000013840
0000000000013840
[ 8390.933163] Call Trace:
[ 8390.933163] [<ffffffff813b9878>] ? read_pmtmr+0x10/0x17
[ 8390.933163] [<ffffffff810e03e7>] ? sync_page+0x0/0x4d
[ 8390.933163] [<ffffffff8148ad2f>] io_schedule+0x47/0x62
[ 8390.933163] [<ffffffff810e0430>] sync_page+0x49/0x4d
[ 8390.933163] [<ffffffff8148b1cc>] __wait_on_bit_lock+0x46/0x8f
[ 8390.933163] [<ffffffff810e038c>] __lock_page+0x66/0x6d
[ 8390.933163] [<ffffffff8107374c>] ? wake_bit_function+0x0/0x31
[ 8390.933163] [<ffffffff8111ec72>] lock_page+0x3d/0x41
[ 8390.933163] [<ffffffff8111f61d>] move_to_new_page+0x11e/0x195
[ 8390.933163] [<ffffffff8111f9fc>] migrate_pages+0x24e/0x38d
[ 8390.933163] [<ffffffff8111501d>] ? compaction_alloc+0x0/0x29a
[ 8390.933163] [<ffffffff810f523b>] ? zone_page_state_add+0x2f/0x34
[ 8390.933163] [<ffffffff81115735>] compact_zone+0x3f0/0x5e1
[ 8390.933163] [<ffffffff81115ad9>] compact_zone_order+0xb0/0xbf
[ 8390.933163] [<ffffffff810e6bc6>] ? get_page_from_freelist+0x627/0x670
[ 8390.933163] [<ffffffff81115b79>] try_to_compact_pages+0x91/0xe7
[ 8390.933163] [<ffffffff810e6cb8>] __alloc_pages_direct_compact+0xa9/0x16f
[ 8390.933163] [<ffffffff810e71e7>] __alloc_pages_nodemask+0x469/0x762
[ 8390.933163] [<ffffffff81123b15>] ? signal_pending+0x17/0x21
[ 8390.933163] [<ffffffff81111c69>] alloc_pages_current+0xb1/0xca
[ 8390.933163] [<ffffffff81119f3f>] alloc_slab_page+0x1c/0x4a
[ 8390.933163] [<ffffffff8111a9f7>] new_slab+0x52/0x1a7
[ 8390.933163] [<ffffffff8111b2dd>] __slab_alloc+0x224/0x302
[ 8390.933163] [<ffffffff8124078b>] ? radix_tree_preload+0x34/0x85
[ 8390.933163] [<ffffffff8124078b>] ? radix_tree_preload+0x34/0x85
[ 8390.933163] [<ffffffff8111b953>] kmem_cache_alloc+0x5b/0xe1
[ 8390.933163] [<ffffffff8124078b>] radix_tree_preload+0x34/0x85
[ 8390.933163] [<ffffffff810e0740>] add_to_page_cache_locked+0x58/0x124
[ 8390.933163] [<ffffffff810e0836>] add_to_page_cache_lru+0x2a/0x58
[ 8390.933163] [<ffffffff810e0b58>] find_or_create_page+0x5a/0x8a
[ 8390.933163] [<ffffffffa0533e2c>] prepare_pages.clone.9+0xf1/0x30a
[btrfs]
[ 8390.933163] [<ffffffffa05143c0>] ? block_rsv_add_bytes+0x24/0x4e [btrfs]
[ 8390.933163] [<ffffffffa0534358>]
__btrfs_buffered_write.clone.11+0x126/0x2a1 [btrfs]
[ 8390.933163] [<ffffffff8114a01c>] ? __mark_inode_dirty+0x30/0x169
[ 8390.933163] [<ffffffff8113f534>] ? file_update_time+0xf7/0x111
[ 8390.933163] [<ffffffffa05348ad>] btrfs_file_aio_write+0x3da/0x492
[btrfs]
[ 8390.933163] [<ffffffff81133939>] ? pipe_read+0x3bd/0x3d2
[ 8390.933163] [<ffffffff810d98a7>] ? __perf_event_task_sched_out+0x27/0x2c
[ 8390.933163] [<ffffffff8112b7e2>] do_sync_write+0xcb/0x108
[ 8390.933163] [<ffffffff811f72da>] ? security_file_permission+0x2e/0x33
[ 8390.933163] [<ffffffff8112be61>] vfs_write+0xac/0xff
[ 8390.933163] [<ffffffff8112c068>] sys_write+0x4a/0x6e
[ 8390.933163] [<ffffffff8100ac42>] system_call_fastpath+0x16/0x1b
Jeremy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs hang in flush-btrfs-5
2011-07-11 11:40 ` Jeremy Sanders
@ 2011-07-11 14:30 ` Josef Bacik
2011-07-11 21:21 ` Jeremy Sanders
0 siblings, 1 reply; 6+ messages in thread
From: Josef Bacik @ 2011-07-11 14:30 UTC (permalink / raw)
To: Jeremy Sanders; +Cc: linux-btrfs
On 07/11/2011 07:40 AM, Jeremy Sanders wrote:
> Jeremy Sanders wrote:
>
>> Hi - I'm trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora
>> kernel). I'm just doing a tar-to-tar copy onto the file system with
>> compress- force=zlib. Here are some traces of the stuck processes.
>
> I've managed to reproduce the hang using the latest btrfs from the
> repository. I had to remove some of the tracing lines to get it to compile
> under 2.6.38.8 and an ioctl which wasn't defined. Here is is where it is
> stuck:
>
Hrm well that is just unlikely and hard to hit. Will you try this and
see if it helps you? Thanks,
Josef
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 59cbdb1..3c8c435 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -1081,7 +1081,8 @@ static noinline int prepare_pages(struct
btrfs_root *root, struct file *file,
again:
for (i = 0; i < num_pages; i++) {
- pages[i] = grab_cache_page(inode->i_mapping, index + i);
+ pages[i] = find_or_create_page(inode->i_mapping, index + i,
+ GFP_NOFS);
if (!pages[i]) {
faili = i - 1;
err = -ENOMEM;
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: btrfs hang in flush-btrfs-5
2011-07-11 14:30 ` Josef Bacik
@ 2011-07-11 21:21 ` Jeremy Sanders
2011-07-13 14:55 ` Josef Bacik
0 siblings, 1 reply; 6+ messages in thread
From: Jeremy Sanders @ 2011-07-11 21:21 UTC (permalink / raw)
To: linux-btrfs
Josef Bacik wrote:
> On 07/11/2011 07:40 AM, Jeremy Sanders wrote:
>> Jeremy Sanders wrote:
>>
>>> Hi - I'm trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora
>>> kernel). I'm just doing a tar-to-tar copy onto the file system with
>>> compress- force=zlib. Here are some traces of the stuck processes.
>>
>> I've managed to reproduce the hang using the latest btrfs from the
>> repository. I had to remove some of the tracing lines to get it to
>> compile under 2.6.38.8 and an ioctl which wasn't defined. Here is is
>> where it is stuck:
>>
>
> Hrm well that is just unlikely and hard to hit. Will you try this and
> see if it helps you? Thanks,
It's got quite a bit further past than where it got before and hasn't
crashed yet. I will let you know when it has finished ok.
I see that the btrfs-delalloc (rather than endio-write) thread is taking up
100% of CPU and the write speed seems to have dropped during the copying,
however. The copy started with using endio-write fully on both cores and now
is using dealloc a lot.
Jeremy
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs hang in flush-btrfs-5
2011-07-11 21:21 ` Jeremy Sanders
@ 2011-07-13 14:55 ` Josef Bacik
0 siblings, 0 replies; 6+ messages in thread
From: Josef Bacik @ 2011-07-13 14:55 UTC (permalink / raw)
To: Jeremy Sanders; +Cc: linux-btrfs
On 07/11/2011 05:21 PM, Jeremy Sanders wrote:
> Josef Bacik wrote:
>
>> On 07/11/2011 07:40 AM, Jeremy Sanders wrote:
>>> Jeremy Sanders wrote:
>>>
>>>> Hi - I'm trying btrfs with kernel 2.6.38.8-32.fc15.x86_64 (a Fedora
>>>> kernel). I'm just doing a tar-to-tar copy onto the file system with
>>>> compress- force=zlib. Here are some traces of the stuck processes.
>>>
>>> I've managed to reproduce the hang using the latest btrfs from the
>>> repository. I had to remove some of the tracing lines to get it to
>>> compile under 2.6.38.8 and an ioctl which wasn't defined. Here is is
>>> where it is stuck:
>>>
>>
>> Hrm well that is just unlikely and hard to hit. Will you try this and
>> see if it helps you? Thanks,
>
> It's got quite a bit further past than where it got before and hasn't
> crashed yet. I will let you know when it has finished ok.
>
> I see that the btrfs-delalloc (rather than endio-write) thread is taking up
> 100% of CPU and the write speed seems to have dropped during the copying,
> however. The copy started with using endio-write fully on both cores and now
> is using dealloc a lot.
>
When you see that can you get sysrq+w or sysrq+t to get a stacktrace of
what it's doing so I can see if it's something that can be fixed. Thanks,
Josef
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-07-13 14:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-08 10:58 btrfs hang in flush-btrfs-5 Jeremy Sanders
2011-07-09 13:13 ` Jeremy Sanders
2011-07-11 11:40 ` Jeremy Sanders
2011-07-11 14:30 ` Josef Bacik
2011-07-11 21:21 ` Jeremy Sanders
2011-07-13 14:55 ` Josef Bacik
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.