On 20/11/13 20:00, Martin wrote: > On 20/11/13 17:08, Duncan wrote: >> Martin posted on Wed, 20 Nov 2013 06:51:20 +0000 as excerpted: >> >>> It's now gone back to a pattern from a full week ago: >>> >>> (gdb) bt #0 0x000000000042d576 in read_extent_buffer () >>> #1 0x000000000041ee79 in btrfs_check_node () >>> #2 0x0000000000420211 in check_block () >>> #3 0x0000000000420813 in btrfs_search_slot () >>> #4 0x0000000000427bb4 in btrfs_read_block_groups () >>> #5 0x0000000000423e40 in btrfs_setup_all_roots () >>> #6 0x000000000042406d in __open_ctree_fd () >>> #7 0x0000000000424126 in open_ctree_fs_info () >>> #8 0x000000000041812e in cmd_check () >>> #9 0x0000000000404904 in main () >>> >>> >>> I don't know if that has gone through that pattern during the week but >>> at a-week-a-time, this is not going to finish in reasonable time. >>> >>> How come so very slow? >>> >>> Any hints/tips/fixes or abandon the test? >> >> You're a patient man. =:^) > > Sort of... I can leave it running in the background until I come to need > to do something else with that machine. So... A bit of an experiment.
Until... No more... And just as the gdb bt shows something a little different! (gdb) bt #0 0x000000000041ddc4 in btrfs_comp_keys () #1 0x00000000004208e9 in btrfs_search_slot () #2 0x0000000000427bb4 in btrfs_read_block_groups () #3 0x0000000000423e40 in btrfs_setup_all_roots () #4 0x000000000042406d in __open_ctree_fd () #5 0x0000000000424126 in open_ctree_fs_info () #6 0x000000000041812e in cmd_check () #7 0x0000000000404904 in main () Nearly done or weeks yet more to run? The poor thing gets killed in the morning for new work. Regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
