Tobias Grosser
2014-Apr-09 07:45 UTC
Re: dm-crypt + btrfs preformance - long lockups during io
On Sat, Apr 5, 2014 at 10:54 AM, Anders Aagaard <aagaande@xxxxxxxxx> wrote: > Hi > > I just recently repartitioned my harddrive, and in the process switched from > ext4+ecryptfs to dm-crypt and btrfs. I'm on ubuntu 14.04, using kernel > 3.14.0-031400-generic. I'm using a intel ssd, which btrfs detects (ssd mode > enabled according to dmesg). I also saw and still see lockups on linux 3.8 with a similar configuration. btrfs on dm-crypt with SSD mode. I use slightly different mount options: /dev/mapper/sda4_crypt on /home type btrfs (rw,noatime,flushoncommit,subvol=@home) /dev/mapper/sda4_crypt on /store type btrfs (rw,subvol=@store) /dev/mapper/sda4_crypt on /home/grosser type btrfs (rw,noatime,flushoncommit,subvol=@grosser) (I previously also used compression. This is disabled at the moment, but compressed files are still around) latencytop gives the following information: firefox: 22909.8 ms latency, cause fsync() on a file The corresponding backtrace is: btrfs_log_inode_parent [btrfs] btrfs_log_dentry_safe [btrfs] btrfs_sync_file [btrfs] do_fsync sys_fsync system_call_fastpath There are also 6 processes called btrfs-endio-wri?? with 1050-1391 ms latency due to [sleep_on_page]. The corresponding backtraces are (3x): sleep_on_page wait_on_page_bit read_extent_buffer_pages [btrfs] btree_read_extend_buffer_pages.constprop.119 [btrfs] read_tree_block [btrfs] read_node_slot [btrfs] push_leaf_right [btrfs] split_leaf [btrfs] btrfs_search_slot [btrfs] btrfs_csum_file_blocks [btrfs] add_pending_csums.isra.42 [btrfs] btrfs_finish_ordered_io [btrfs] 1x: sleep_on_page wait_on_page_bit read_extent_buffer_pages [btrfs] btree_read_extend_buffer_pages.constprop.119 [btrfs] read_tree_block [btrfs] read_block_for_search.isra.51 [btrfs] btrfs_search_slot [btrfs] btrfs_insert_empty_items [btrfs] run_clustered_refs [btrfs] btrfs_run_delayed_refs [btrfs] __btrfs_end_transaction [btrfs] btfs_end_transaction [btrfs] 1x sleep_on_page wait_on_page_bit read_extent_buffer_pages [btrfs] btree_read_extend_buffer_pages.constprop.119 [btrfs] read_tree_block [btrfs] read_node_slot [btrfs] push_leaf_left [btrfs] split_leaf [btrfs] btrfs_search_slot [btrfs] btrfs_insert_empty_items [btrfs] btrfs_csum_file_blocks [btrfs] add_pending_csums.isra.42 [btrfs] 1x sleep_on_page wait_on_page_bit read_extent_buffer_pages [btrfs] btree_read_extend_buffer_pages.constprop.119 [btrfs] read_tree_block [btrfs] read_node_slot [btrfs] push_leaf_right [btrfs] split_leaf [btrfs] btrfs_search_slot [btrfs] btrfs_csum_file_blocks [btrfs] add_pending_csums.isra.42 [btrfs] btrfs_finish_ordered_io [btrfs] At the moment of deadlock, I am just running normal desktop applications like thunderbird and firefox. Cheers, Tobias Any idea where such long delays may come from. -- 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