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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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; -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Apparently Analagous Threads
- dmesg error
- Interesting problem with write data.
- [PATCH] OCFS2: Pagecache usage optimization on OCFS2
- xen, lvm, drbd, bad kernel messages
- Bug#603727: xen-hypervisor-4.0-amd64: i386 Dom0 crashes after doing some I/O on local storage (software Raid1 on SAS-drives with mpt2sas driver)